This is true for very simple applications, where you’re just running `npm ci` or `pip install`, but breaks down as soon as you have sophisticated dependencies with system / library requirements or dependencies (e.g. databases, caches, message brokers, queues) that are beyond the scope of asdf.
Also, since you’re probably deploying containers to production, it’s useful to have a similar environment for local development so that you know what will actually happen in production.
Citation needed I feel - I’d wager the number of containerized deployments pales in comparison to the number of binaries scp’d into a production host.
I said “probably” because the vast majority of deployments I’ve done over the past decade have been containerized, but I have no trouble believing that my experience isn’t indicative of the average.
Docker is NOT about local dev, it's about deployment.
We forgot this...
I mean... if Vagrant can be about local development, I don't see why Docker can't be about local development too.
Do you want to quickly debug some software that relies on an older version of Postgres 9 but you don't want to clutter your host machine? Just run the following command to fetch and start an instance. With --rm flag it's going to be removed as soon as you terminate it:
docker run --rm -p 5432:5432 postgres:9
But that was never the primary purpose of Docker. Like I can use Mac Minis as door stops, etc.
Docker runs best on top of Linux. As in actually run a Linux host , everything else in my experience is a hack. As long as you have internet access, spinning up an ec2 instance to test stuff shouldn't be too hard.
This such a complete and utter lie and I'm surprised people in 2022 still believe it.
You do know what's happening when you run Docker on your Macbook, right? Right?
I used Docker to run the application using the exact same image that was deployed to production, and was able to replicate the issue.
Why? Because the PDF renderer depended on loads of finicky dependencies (e.g. linked libraries), and it turns out that the default fonts in our base image didn’t support the Unicode code points in the example payload. I couldn’t replicate this outside of Docker because I have a completely different set of linked libraries and don’t stack.
Happy to answer any questions you have.
the other post mentioned setup, so i thought he meant they imposed presetup containers for developers to use?
A Linux vm spawns a process with new namespaces - which is often exactly what happens in production as well.
There are two possibilities - a) you are right, you know something your company doesn't, and by proposing your new plan in a constructive manner you might make life better for everyone b) you are wrong, you don't fully comprehend the surface area of the software you are working on, and your suggestion is short sighted and doesn't account for all of the requirements.
Either way it is helpful to put it out there - so long as you do it from the right place, with the right intention. Either you'll humble yourself, or you will eliminate an unnecessary dependency and make life easier for your team.
In the "big 'ol" companies I worked at, something like that takes months! If even possible...
But countless developers in countless companies have each their own set of frustrations where they sense that something could be improved but don't know what to do with the frustration.
Frustrations are a useful symptom but learned helplessness is a terrible thing that can lead to anything from being annoyed to leaving your job to depression.
I would argue that the response was in fact a very valuable lesson.
It is totally valid to point out failures in something without knowing how to put them right, or being in a position to do so.
Complaining for complaining is not helpful, but don't dismiss problems because no one can think of a better solution at the same time.
It is NOT great for having a live-reloading dev webservice running. People seem to swing for an all in one solution, but consideration is needed about what services you want in docker or not. Docker is great to have preconfigured database environments that are easy to tear down and start from scratch and works across multiple platforms. Docker is bad for local dev server.
Oh my god this.
I was running a fastapi server on my m1 Mac in an arm Linux docker container. Everything else works great in this, but the live-reloading server was running at 200% cpu and ate 50% of my battery life!
- docker is good when the deployed software runs on docker too, because dev and prod are the same and on Linux the performance hit is negligible if any. If you're on Mac or Windows it seems that it can be felt.
- docker is a good way to distribute the development environment, anecdotally much better than Vagrant or bare VMs.
- However having to always prefix commands with docker exec container is a little pain. Working in docker exec container bash is worse.
- Sharing only volumes between the host file system and docker means that sometimes I have to copy files to the shared volume instead of addressing them where they are.
- asdf doesn't have all those problems but I must be careful to pick different ports for different postgresql servers in different projects. Docker would shield those ports inside the network of the project.
All considered, I use docker when a customer uses docker, VMs when a customer uses VMs, asdf for all the other cases including my own software which I never deployed to docker so far. If I did I'd probably work in docker because I don't want surprises at deployment time.
I’m not saying this is the right way but this is very common. I also agree with the rest of your points.
docker-compose build
docker-compose run --rm api bundle
docker-compose up
One developer has a M1 Mac and he's using something called mutagen instead of docker. His docker-compose.yml is a little different and he's paying a performance penalty. His M1 is only 50% faster than my Intel from 2014 at running the test suite (50 seconds vs 75.) The difference is not noticeable when running only a few tests per time when working on a single feature.
docker compose
docker-compose
The new 'docker compose' command is currently experimental.On a workstation level, people who really know their way around stuff tend to dislike docker in my experience, and for people who don't its still too difficult. One problem I think it has is that docker - still talking about workstations here - solves mostly problems on the team level, not on an individual level. But individuals tend to regard those problems as 'other peoples problems'.
Another problem is that you can work with docker just fine with barely knowing how it works, until there's a problem. In my experience, developers tend to immediately blame docker for the problem, even though its a misconfiguration of non which they would also have in a native installation.
Still, docker solves a lot of problems that aren't solved by asdf, apt or rpm, which is why it continues to be relevant and used also for workstations.
Docker basically just takes a snapshot, which hides the problem rather than fixing it: when we want to change something, like updating a dependency, we're back to the same dependency hell.
Even worse, those snapshots are often not reproducible (e.g. running things like `apt-get install -y foo`, which depends on the latest contents of third-party servers). Again, Docker tries to hide the problem by putting snapshots into a cache.
To avoid these problems, we need the discipline to do sensible things (e.g. using specific .deb packages, rather than apt-getting whatever's latest; or using something more brute-force like Nix). Yet once we do that, there's usually no point doing it with Docker at all; since those commands work perfectly well outside of a container (if we want a container to deploy, we can tar up the resulting directory)
I hope you don't COPY your entire system into the container at least.
I can't recall ever encountering such a thing myself. On the other hand, I've seen LOTS of this sort of thing:
RUN apt-get update && \
apt-get -y install apache2
As I mentioned above, when the instructions are reproducible, there's no point using Docker to run them; a shell script would suffice.
[1] https://docs.aws.amazon.com/AmazonECS/latest/developerguide/...
That's not reproducible in the sense of "reproducible software", but it is usually good enough to build other things on top of.
If you want reproducible in the sense of unchaging/same digest, you should make a custom base image with the things you never want to change and pull it from somewhere.
For example, asdf can install tools on a developer's system. asdf can route invocations to the appropriate version of an installed tool.
Docker can be used to install tools in isolation by way of an image build. That image can be shipped off, so that developers can pull the image, and do not have to run an installation procedure. Docker can pull and run the appropriate version on demand upon invocation.
It's also not a binary choice. You can use asdf in a Docker container, and you could use Docker in an asdf plugin.
I also hate the Docker tagline that it "eliminates 'works on my machine' issues". I believe a tool like asdf would also achieve this (correct me if I'm wrong). Docker itself can go haywire depending on the machine and you're basically in hell fighting with it just to get your dev environment working. You essentially eliminate one problem in exchange for a variety of equally frustrating challenges.