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

41–50 of 66 posts

Re: Developing with Docker

#41

Post by hluska »

I find this topic very interesting. On one hand, I am sure that every person reading this has run into a ‘bug’ introduced because of a dev/prod mismatch. On the other hand, the only way to get a total match is to either pay an obscene amount of money or roll everything yourself (which will also have cost, much of which can never be recovered).

As an example, I can build something, deploy it on my own and create a near one to one match. But that means building everything and never using a managed service. If the application interfaces with another tool like Salesforce, do we have multiple instances for every single developer?

Or, do we roll our own CRM?

Matching is great but in a managed world it’s very expensive.

Re: Developing with Docker

#42

Post by hluska »

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…

There’s really nothing complicated in the docker-compose listed. It’s simple, uses some very simple commands that everyone should know and sets environment variables at build.

We also have code reviews. They’re helpful with containers because sometimes people do silly things when they can. But that’s why we have code reviews in the first place.

Re: Developing with Docker

#43

Post by marliechiller »

ewuhic wrote: post #4

>but importantly, the image at each of these stages is exactly the same: reproducible at every turn This is wrong. Hadn't read any further. Regards, NixOS adept

Arise NixOS acolytes, arise!

All jokes aside, to expand on this for others, you can fix a lot of dependencies but as soon as you start your dockerfile with a FROM, youre hiding a bunch of dependencies which you no longer control, behind that command. An example would be:

FROM tiangolo/uvicorn-gunicorn-fastapi

If tiangolo decides to update anything in the base image defined here, your build is now different to how it was before without really knowing

Re: Developing with Docker

#44

Post by c-hendricks »

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

Docker for local development is only useful for running services like Postgresql and Redis, or doing hot reloads using something like vite or air. The development in a box paradigm is really difficult to maintain, much prefer direnv or nix.

Yup, at work we've been doing "dev machine bootstrap script installs version managers (nvm/mise/direnv/etc), projects use those" and have been experimenting with direnv + nix.

Re: Developing with Docker

#45

Post by alexkbog »

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…

Whereas this was true (for a long time), making an argument that because remote and local are so “inherently” different that one shouldn’t strive for this parity is silly, especially considering the differences outlined are pretty easily solvable by k8s to local parity.

Whereas it’s still clunky to dev with tools like skaffold and minikube, I strongly believe they are the future. We have essentially eliminated deployment bugs using skaffold for local dev and deployment. Everything is caught locally, on a dev machine or in CI, as it should be.

Re: Developing with Docker

#46

Post by Joe_Cool »

mpettitt wrote: post #18

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

That's a good idea. I usually have a 'myproject-debugtools' container that just operates on the same volume and maybe even shares a network with the 'myproject-prod' container. Just set it to `--restart no` and even when someone forgets to shut it down it'll be gone on reboot. That way all the non-prod stuff isn't even in the image at any point.

Or if that is too much work just have a 'myproject-dev' image/tag if you need to debug a live environment.

Re: Developing with Docker

#47

Post by tomberek »

remram wrote: post #32

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

Agreed. Packaging is different than deployment. Devs should return to the art of packaging, such that their software can be then deployed into containers, VMs, micro VMs, whatever. That is what packaging allows, re-use.

This is the sort of behavior Nix encourages (disclaimer: I work at https://flox.dev , using Nix as our baseline tech). Docker as both a packaging and deployment format can carry a bit of weight, but can quickly get out of hand.

Re: Developing with Docker

#48

Post by mirekrusin »

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.

Containers are great interface with other teams – ie black box their services, don't care how their things are running, just communicate which envs to use to make it work according to comms spec.

Re: Developing with Docker

#49

Post by alphapug68 »

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 that Docker watch will auto rebuild your container. So it gets around that issue too.

I have a .bat file in our repo that runs the Docker compose action to start up all the needed services and has some powershell to wait until the main UI service is up. When it’s up it auto opens the web browser.

I have a docker container that uses Dozzle (https://dozzle.dev/) for log monitoring across the various services. It can also stop/restart containers if needed.

I also have a container that can be ran to perform a database restore from an external Postgres DB into a local Postgres Docker container.

I will say that dotnet debugging is clunky. You can attach to the Docker container in Visual Studio but if a hot reload has happened you can’t debug again until the app has restarted. For dotnet if I need to do some intensive debugging I tend to spin it up outside Docker for this reason.

Re: Developing with Docker

#50

Post by hiatus »

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.

Post reply on HN