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

31–40 of 66 posts

Re: Developing with Docker

#31

Post by stackskipton »

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…

Sounds like yall are doing a poor job building the container. It's one thing to rely on built in musl/glibc if it's modern software. However, if you are dragging technical debt, all those dependencies should be hard locked to the proper version.

Re: Developing with Docker

#32

Post by remram »

Docker is a deployment mechanism. This means publishing Docker images is a deployment activity not a development one.

I don't think software developers should publish Docker images at all [1]. This is a huge impedance mismatch with serious security implications. In particular, your Docker image needs a regular release cadence that is different from your software releases.

Including a Dockerfile is fine, they allow the person doing the deployment to customize/rebuild the image as needed (and help with development and testing too).

[1]: Though I'm not saying you can't be both a developer and sysadmin in your organization. Are you?

Re: Developing with Docker

#33

Post by chambored »

ggregoire wrote: post #24
vhiremath4 wrote: post #15

Earlier quoted context omitted.

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.

You can also pass an entire .env file with the --env-file option.

And in the env_file attribute in your compose yaml

Re: Developing with Docker

#34

Post by trevor-e »

stackskipton wrote: post #28
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…

If you are using VSCode, you can run VSCode inside a container. Otherwise, most people run the code environment outside a container. Also, read 12 Factor, logging to a file is wrong. Logs go to standard out.

Thanks for the 12 Factor tip, makes sense.

Re: Developing with Docker

#35

Post by stackskipton »

jmathai wrote: post #30

I’ve been writing software for 20+ years. Sometimes I feel like I’m the only one who hasn’t had the problems Docker solves.

Depends on the language and deployment method. Windows anything on .Net Framework. Sure, why use Docker?

C++ CSV parser, yep, Docker generally doesn't make sense since it's ship the executable and done.

However, Python/Java/.Net where you can't be sure of run time? Container. Node with a ton of random packages? Container

Need to manage a big fleet of software? Containers enable a ton of container orchestration engines.

Re: Developing with Docker

#36

Post by chambored »

f1shy wrote: post #8
c-hendricks wrote: post #3

I love Docker (more so the idea of containers). Use it almost everywhere: self hosting services, at work everything is deployed as a docker container. Except local development. Absolutely hate the "oh need to add a dependency, gotta rebuild everything" flow. I do use it if the project I'm developing against needs a DB/redis/etc, but I don't think there's a chance I'm going back to using it for local development. In f…

I hate container and Docker in ANY use-case where there is an alternative that is same, or even "a little bit" more involved. I reserve Docker and Containers for that use case where I really would have headaches if it is no there, and have not still found such a case in all the works I've done.

Everyone has different thresholds.

Re: Developing with Docker

#37

Post by remram »

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 mount a file with the secret in it. This is often recommended anyway because environment variables are inherited by linked libraries and subprocesses, making it too easy for some third-party code to leak.

Re: Developing with Docker

#38

Post by chambored »

kitd wrote: post #20

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. T…

I agree with this. For multi-OS dev teams, I’ve set up separate compose files or Dockerfiles for dev and prod. I kept them as similar as possible while optimizing the images for prod and including the niceties for dev.

Re: Developing with Docker

#39

Post by chambored »

jpgleeson wrote: post #13
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…

I found setting up nix shells to be more time consuming than docker setups. Nixpkgs can require additional digging to find the correct dependencies that just work on other distributions. That being said, I’m a huge fan of NixOS, but I haven’t seen it as a replacement for docker for reproducible dev environments yet.

Re: Developing with Docker

#40

Post by d_watt »

threemux wrote: post #14

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 un…

I mean, having a web, worker, cache, db, and search as separate things doesn't seem that crazy?

While of course you can often get away with just a web with sqlite, pretty much any company of scale I've been at maintain those all as separate things, with separate search as the most optional.

What do you feel about the setup described seems overly complicated?

Post reply on HN