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

21–30 of 66 posts

Re: Developing with Docker

#21

Post by cornstalks »

vhiremath4 wrote: post #15
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.

I understand that at a high level, but the implementation is where I get lost and where I'd love an article like this to tell me how to do it and how to deploy securely vs develop locally. Most of the guides I've seen involving a secrets manager assume you're very comfortable with Docker, but I'm still trying to figure it out and need some hand holding like this article does.

Re: Developing with Docker

#22

Post by horsawlarway »

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…

Generally speaking - you can just mount the local directory in the container (this is particularly easy with docker compose) during development.

https://docs.docker.com/engine/storage/bind-mounts/

Then there's no need to rebuild or restart your container while developing.

For debugging, it depends a bit on the tool - anything that expects to interact through a network port is very straightforward (just expose the port locally, and run the tool as usual). If it needs more than that, it can be more complex.

Re: Developing with Docker

#23

Post by JohnMakin »

> At it's simplest, stuff like this: if ENVIRONMENT == "prod": do_something_only_production_does() ...shouldn't happen.

This is a common refrain among people that IMO do not have a lot of experience in big, complex systems, especially ones running a lot of legacy code. Like, ideally, sure, but in reality making this possible almost always involves extra cost, time, and complexity, and what do you gain from that, really? It's a pretty concept, but not at all practical.

Re: Developing with Docker

#24

Post by ggregoire »

vhiremath4 wrote: post #15
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.

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

Re: Developing with Docker

#25

Post by JohnMakin »

d_watt wrote: post #11

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

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

ditto, "worked on local" is a meme for a reason.

Re: Developing with Docker

#26

Post by vhiremath4 »

d_watt wrote: post #11

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

After going through a bunch of evolutions using Docker as co-founder/engineer #1 at a startup to > 100 engineers, hard agree on this take.

One other reason to not overbloat your images (besides physical storage cost and perf) is security considerations. If you find yourself in a place where you need to meet enterprise security standards, keeping more dependencies in your image and linked to your app code widens your risk vector for vulnerabilities.

Re: Developing with Docker

#27

Post by jgauth »

> What if running the linters was as easy as: $ docker compose exec web /scripts/run-linters

This seems to ignore the fact that I also run linters in my IDE to get immediate feedback as I’m writing code. As far as I know there’s no way to combine these two approaches. Currently I’m just careful to make sure my local ruff version matches the one used in CI.

It may be possible with VS Code dev containers, but last time I looked at those I was turned off by the complexity.

Re: Developing with Docker

#28

Post by stackskipton »

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.

Re: Developing with Docker

#29

Post by d_watt »

cornstalks wrote: post #21
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.

I understand that at a high level, but the implementation is where I get lost and where I'd love an article like this to tell me how to do it and how to deploy securely vs develop locally. Most of the guides I've seen involving a secrets manager assume you're very comfortable with Docker, but I'm still trying to figure it out and need some hand holding like this article does.

I think this is mostly because that's out of scope of responsibility of docker, and docker compose (for the most part) is only a local dev tool without prod concerns.

For deploying docker containers to production, and how to manage secrets, you'd need to look to that container orchestrator's recommendations. EG K8S secrets. It doesn't make too much sense to put an example of how to use production secrets in a docker guide, because those belong in a K8S/GKS/EKS/DO etc tutorial.

Docker's "interface" is how to accept env variables, it's other parts of the system that need to set those variables.

Post reply on HN