Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Developing with Docker

danielquinn.org

Post reply on HN
Print view View original

11–20 of 66 posts

Re: Developing with Docker

#11

Post by d_watt »

I don't think I agree with this. Docker is an amazing tool, I've used it for everything I've done in the last 7 years, but this is not how I'd approach it.

1. I think the idea of local-equal-to-prod is noble, and getting them as close as possible should be the goal, but is not possible. In the example, they're using a dockerized postgres, prod is probably a managed DB service. They're using docker compose, prod is likely ECS/K8S/DO/some other service that uses the image (with more complicated service definitions). Local is probably some VM linux kernel, prod is some other kernel. Your local dev is using mounted code, prod is probably baked in code. Maybe local is ARM64, and prod is AMD64.

I say this not because I want to take away from the idea of matching dev and prod as much as possible, but to highlight they're inherently going to be very different. So deploying your code with linters, or in debug mode, and getting slower container start times at best, worse production performance at worse - just to pretend envs which are wildly different aren't different seems silly. Moreover if you test in CI, you're much more likely to get to a prod-like infra than a laptop.

2. Cost will also prohibit this. Do you have your APM service running on every dev node, are you paying for that for all the developer machines for no benefit so things are the same. If you're integrating with salesforce, do you pay for a sandbox for every dev so things are the same. Again, keeping things as similar as possible should be a critical goal, but their are cost realities that again make that impossible to be perfect.

3. In my experience if you actually want to achieve this, you need a remote dev setup. Have your code deployed in K8S / ECS / whatever with remote dev tooling in place. That way your DNS discovery is the same, kernels are the same, etc. Sometimes this is worth it, sometimes it isn't.

I don't want to be negative, but if one of my engineers came to me saying they wanted to deploy images built from their machine, with all the dev niceties enabled, to go to prod, rather than proper CI/CD of prod optimized images, I'd have a hard time being sold on that.

Re: Developing with Docker

#12

Post by cornstalks »

The one thing I feel like is missing in guides like this is key management. I don't like the idea of putting secret keys in my compose.yaml and I would prefer to use something more... controllable? Auditable? The thing is, I don't really know, because this isn't the kind of stuff I work on for $dayjob. But I can't help but feel like there's something missing with key management, and for a noob like me I don't know how to fit it into the larger puzzle.

Re: Developing with Docker

#13

Post by jpgleeson »

brendanjbond wrote: post #6

This is all very good and true, but as usual the devil is found in the details. For instance, my company sells Docker images that depend on a very old and recently unmaintained binary. Over the years, I've found issues with that binary that make it very hard to be sure issues are completely reproducible from system to system (or, as the article suggests, from local to production). Sometimes, it's as simple as a newer…

These are the sort of issues that Nix https://nixos.org/> solves quite well. Pinning dependencies to specific versions so the only time dependencies change is when you explicitly do it - and the only packages present in your images are ones you specifically request, or dependencies of those packages. It also gives you local dev environments using the ~same dependencies by typing `nix develop`.

Once you get past the bear that is the language, it's a great tool.

Re: Developing with Docker

#14

Post by threemux »

This demonstrates the most pernicious thing about Docker: it is now easier than ever for someone to design a Rube Goldberg machine and then neatly sweep it under the rug.

When you see the dev environment setup described, the knee jerk reaction should be to simplify it, not to automate the running of 30 disparate commands. Then you can much more easily run it in production, instead of boxing up the mess and waiting until you actually have to debug it.

Re: Developing with Docker

#15

Post by vhiremath4 »

cornstalks wrote: post #12

The one thing I feel like is missing in guides like this is key management. I don't like the idea of putting secret keys in my compose.yaml and I would prefer to use something more... controllable? Auditable? The thing is, I don't really know, because this isn't the kind of stuff I work on for $dayjob. But I can't help but feel like there's something missing with key management, and for a noob like me I don't know ho…

You can inject keys into the running container by passing them as environment variables during the docker run command, ideally supplied via a secrets manager.

Re: Developing with Docker

#16

Post by trevor-e »

As someone new to Docker, the thing that is never answered (including in this post, the irony of the title...) is what an actual dev workflow looks like.

Let's say I'm working on a web app. I start my container, awesome. Now I make a code change. What do I do? Since the code is copied in the container, do I have to stop, rebuild the image, and start again? Or does it automagically rebuild like most frameworks support? And how about debugging, are there any hoops to jump through connecting a debugger to a container? And what about the filesystem. If I need to inspect the output of something, say a log file in the container, is that easy to do? I've tried this before and got pretty lost trying to access the filesystem.

None of these questions are obvious to Docker beginners like myself. We get the whole "consistent environment" benefits of Docker, now talk about a practical workflow please. :)

edit: thanks for the answers!

Re: Developing with Docker

#17

Post by yjftsjthsd-h »

brendanjbond wrote: post #6

This is all very good and true, but as usual the devil is found in the details. For instance, my company sells Docker images that depend on a very old and recently unmaintained binary. Over the years, I've found issues with that binary that make it very hard to be sure issues are completely reproducible from system to system (or, as the article suggests, from local to production). Sometimes, it's as simple as a newer…

I'll grant that the kernel version+config shifting is a pain point, but I'd expect that containers help with the rest of it (userspace)? Yes, obviously changing the base image is a potential breaking change, but with containers you package up the ancient binary and the base image and any dependencies into a single unit, and then you can test that that whole unit works (including "did that last musl upgrade break the thing?"), and if it passes then you ship the whole image out to your users safe in the knowledge that the application will only be exposed to the libraries you tested it against and no newer versions.

Re: Developing with Docker

#18

Post by mpettitt »

Including developer tooling in a Docker image is missing one of the really useful things about Docker: not needing all that stuff. By using a multi-stage build, you can do all the slow dev stuff at image build time, then only include the output in the image, and that includes things like building a library which wants a different set of conditions to build than your application wants to run.

It also adds an additional level of risk - if your image is compromised, but all that is running in it is your app, oh well. If it's compromised, and it's able to call out to other parts of your stack (yes, some of this is down to the specific deployment process), that's much worse.

Re: Developing with Docker

#19

Post by chc4 »

trevor-e wrote: post #16

As someone new to Docker, the thing that is never answered (including in this post, the irony of the title...) is what an actual dev workflow looks like. Let's say I'm working on a web app. I start my container, awesome. Now I make a code change. What do I do? Since the code is copied in the container, do I have to stop, rebuild the image, and start again? Or does it automagically rebuild like most frameworks support…

You can mount volumes in your Docker containers: what I usually do is mount my host source directory over the container's source directory, so that changes are immediately visible inside the container, and then hot reloading in e.g. Flask works exactly like you expect.

Re: Developing with Docker

#20

Post by kitd » 

    Developer Tooling

    This is where I tend to run into the most pushback on this pattern but it's also the 
    part that can greatly reduce headaches. Are you ready? Your immutable image includes 
    everything you need for development: linters, tests, and debugging modules. I will 
    sometimes even include a few useful system tools like netcat or ping, as well as a 
    fancy prompt.

    None of these things are necessary for production. They are at best, image bloat, 
    adding anywhere from 100 to 200 MB of useless code to your image that's never used in 
    the wild. Why then, would we want to include it?
Sorry, but this is dangerous advice. This won't pass most serious security audits and to use these tools, you'd likely need to be running as root.

Much better is to strip your immutable images to the bare minumum and instantiate a debug sidercar, eg [1], if you need to peer inside.

[1] - https://github.com/mhoyer/docker-swiss-army-knife

Post reply on HN