Live data from Hacker News

Developing with Docker at IFTTT

medium.com

21–29 of 29 posts

Re: Developing with Docker at IFTTT

#21
post #2

Nice to see a post that covers the various aspects of using Docker in place of some like Vagrant for local development. The biggest pain I've run into when using Docker for local dev is waiting for pip to install dependencies on rebuilds. This offers an interesting strategy for mitigating that and I look forward to digging into this more.

Thanks! We experienced that exact same pain. Whether it's pip or Bundler, I can't tell you how many times I've installed and reinstalled requirements. Sharing data volumes is kind of a hack to make it really easy to keep part of a container around when you delete and recreate a container. I would love to see persistent data volumes become first class citizens so you don't have to create a separate container for them.…

You'll be able to create volumes as first class citizens in the next Docker release with the new 'docker volumes' command if I'm not mistaken: https://github.com/docker/docker/blob/4b4597ae17d4fd8843aa93...

Re: Developing with Docker at IFTTT

#22
post #2

Nice to see a post that covers the various aspects of using Docker in place of some like Vagrant for local development. The biggest pain I've run into when using Docker for local dev is waiting for pip to install dependencies on rebuilds. This offers an interesting strategy for mitigating that and I look forward to digging into this more.

I'm not sure if this address your specific pain point, but if your issue is around building images, if you first COPY requirements.txt and then do `pip install` before COPYing the rest of your code into the image, Docker caching will actually cache that layer for you.

Re: Developing with Docker at IFTTT

#23

It seems like using .dev TLD is a bad idea since Google owns it[1]. How many people use the .dev or .local TLD? What's the best practice here? [1] https://www.iana.org/domains/root/db/dev.html

Using anything beside a domain you own and control is a potential bad idea.

Re: Developing with Docker at IFTTT

#24

Earlier quoted context omitted.

.local is actually reserved for such purpose: https://en.wikipedia.org/wiki/.local

It seems to me that .local is reserved for purposes within a local network, not necessarily local to an individual computer itself. You could, for example, set up an internal server on your network and have it resolve with storage.local. You could argue that a collection of containers is basically the same thing, though.

If a container has its own IP address, I think it can be considered its own device on the network, regardless of the details.

Re: Developing with Docker at IFTTT

#25

Earlier quoted context omitted.

Thanks! We experienced that exact same pain. Whether it's pip or Bundler, I can't tell you how many times I've installed and reinstalled requirements. Sharing data volumes is kind of a hack to make it really easy to keep part of a container around when you delete and recreate a container. I would love to see persistent data volumes become first class citizens so you don't have to create a separate container for them.…

You'll be able to create volumes as first class citizens in the next Docker release with the new 'docker volumes' command if I'm not mistaken: https://github.com/docker/docker/blob/4b4597ae17d4fd8843aa93...

Yes, I'm looking forward to it! It will still be a little ways off before we can use it with Compose, however.

Re: Developing with Docker at IFTTT

#26
post #15

Earlier quoted context omitted.

Thanks! We looked at the approach of adding a Gemfile.tip, however we like the data volume approach because it doesn't require any changes to the Dockerfile and it is more like what our developers are familiar with. A Gemfile.tip can become basically another Gemfile eventually, so separating the bundle step from the build step (in Development) gives us more flexibility as well as keeping things more in line with what…

I'm a bit confused by your bundler-cache. It seems you must be running `bundle install` at runtime, because you can't mount that volume during build. Am I misunderstanding?

To add to silvamerica's comment, this process is specific to running containers in development. When building images for deployment the dependencies are installed as a RUN step in the Dockerfile.

Re: Developing with Docker at IFTTT

#27

Hey IFTTT! Jacob from Imgur here. Do you guys think you will be trying Kubernetes soon?

We're currently using Marathon and Chronos, and it's going pretty well. What about y'all?

We're still experimenting with Docker, but aren't using it in production yet. Definitely going to check out these scripts though, especially that dnsmasq container.

Re: Developing with Docker at IFTTT

#28

Earlier quoted context omitted.

.local is actually reserved for such purpose: https://en.wikipedia.org/wiki/.local

OS X does weird stuff with the .local tld, making usage of it for local hosts non-trivial. https://support.apple.com/en-us/HT201275

Not, that weird:

    > Host names that contain only one label in
    > addition to local, for example
    > "My-Computer.local", are resolved using
    > Multicast DNS (Bonjour) by default. Host names
    > that contain two or more labels in addition to
    > local, for example "server.domain.local", are
    > resolved using a DNS server by default.
Apparently there's nothing wrong with adapting, say, .dev.local (or .ifft.local) with a coresponding hack, ahem, file, under /etc/resolver/dev.local:

http://blog.scottlowe.org/2006/01/04/mac-os-x-and-local-doma...

Re: Developing with Docker at IFTTT

#29
post #28

Earlier quoted context omitted.

OS X does weird stuff with the .local tld, making usage of it for local hosts non-trivial. https://support.apple.com/en-us/HT201275

Not, that weird: > Host names that contain only one label in > addition to local, for example > "My-Computer.local", are resolved using > Multicast DNS (Bonjour) by default. Host names > that contain two or more labels in addition to > local, for example "server.domain.local", are > resolved using a DNS server by default. Apparently there's nothing wrong with adapting, say, .dev.local (or .ifft.local) with a corespon…

That looks like a great way to handle it!
Post reply on HN