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

51–60 of 66 posts

Re: Developing with Docker

#51

Post by timbotron »

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…

"widely different" seems like a stretch e.g. ECS is pretty directly translatable to docker compose, and if you do cross-platform builds with buildx then I don't see why doing the building locally or on a cloud service matters much.

Re: Developing with Docker

#52

Post by alphapug68 »

hiatus wrote: post #50
alphapug68 wrote: post #49

I have experimented with a local setup in our team. With the new Docker compose watch functionality I think it works well. https://docs.docker.com/compose/how-tos/file-watch/ For me this has negated the need for manual mounting. I combine the above with dotnet watch —-non-interactive in the dockerfile for dotnet and a simple ng serve in our Angular apps. If new dependencies are added via npm install you can set it so…

> This negates the need for manual mounting. The documentation you linked says it is a complement not a replacement. > Compose supports sharing a host directory inside service containers. Watch mode does not replace this functionality but exists as a companion specifically suited to developing in containers.

I haven’t had the need to mount anything manually for local development. It entirely replaces it for my needs. This is for a stack using some Postgres databases, dotnet, react, node.js and angular.

Re: Developing with Docker

#53

Post by timbotron »

JohnMakin wrote: post #25
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.

but "works on my machine" is exactly the problem docker solves -- if you still have those issues then you're not building your images right

Re: Developing with Docker

#54

Post by zelphirkalt »

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.

One thing Docker helps with is reproducibility. If you write your images properly (not many people do) then you can have exact same conditions for every time you run tests. If you keep databases on the host machine, instead of containers, you will have to have some cleanup steps and automate somehow, that they are always run. Otherwise you risk shaky test results or even false positives/negatives. That might be fine, if the CI runs the tests reliably as well though.

Re: Developing with Docker

#55

Post by stuaxo »

It sounds good, but Docker is also good for all sorts of other patterns too.

For instance: Docker is great for local development that never touches prod.

Docker is great for hybrid local dev, where you run some services in docker but not others.

If your desktop is Linux and you are building python based web services, then running python in a virtualenv is often much more responsive than having to rebuild some docker thing.

Re: Developing with Docker

#56

Post by stuaxo »

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…

Indeed - keeping stuff working inside AND outside docker, is probably a good way of keeping a project honest.

Re: Developing with Docker

#57

Post by johannes1234321 »

stuaxo wrote: post #55

It sounds good, but Docker is also good for all sorts of other patterns too. For instance: Docker is great for local development that never touches prod. Docker is great for hybrid local dev, where you run some services in docker but not others. If your desktop is Linux and you are building python based web services, then running python in a virtualenv is often much more responsive than having to rebuild some docker…

You don't have to rebuild docker things that often. One can mount the local source directory into a container, then one has a relatively well defined (docker containers aren't reproducible builds themselves) runtimes environment (python version, global packages etc.) while editing happens outside the container. Especially useful if one switches between versions etc. regularly.

Re: Developing with Docker

#58

Post by stuaxo »

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.

I wish there was some secrets manager that would give me a per-project env file in somewhere ephemeral like /run (bonus points for it disappearing when the computer is locked).

Keeping a .env file around still is still a vulnerability if a device goes missing.

Re: Developing with Docker

#59

Post by stuaxo »

JohnMakin wrote: post #23

> 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, real…

The Django equivilent is having different settings for prod vs dev, and for good reason: There are things I run in Dev, like the Django Debug Toolbar that I just wouldn't run in prod.

Re: Developing with Docker

#60

Post by lbreakjai »

At work, we took the radically different approach of not having such a thing as a local environment. It won't necessarily work for every tech stack, but we mostly use lambdas, RDS, SQS, dynamoDB, kafka, and S3, so it's trivial to spin up and tear down the stack as we go. Essentially, instead of trying to ship the local machine to prod, we bring prod to the local machine.

It's a breath of fresh air not having to maintain a separate local environment.

Post reply on HN