5 ms·

The best CI/CD pipeline I ever used was my first freelance deployment using Django. I didn't have a clue what I was doing and had to phone a friend. We set up

The best CI/CD pipeline I ever used was my first freelance deployment using Django. I didn't have a clue what I was doing and had to phone a friend. We set up a git post receive hook which built static files and restarted httpd on a git receive. Deployment was just 'git push live master'. While I've used Docker a lot since then, that remains the single easiest deployment I've ever had. I genuinely don't understand what docker brings to the table. I mean, I get the value prop. But it's really not that hard to set up http on vanilla Ubuntu (or God forbid, OpenBSD) and not really have issues. Is the reproducibility of docker really worth the added overhead of managing containers, docker compose, and running daemons on your devbox 24/7?

Shog9 1y ago
Reproducibility? No. Not having to regularly rebuild the whole dev environment because I need to work on one particular Python app once a quarter and its build chain reliably breaks other stuff? Priceless.
- janjongboom 1y ago
  This false sense of reproducability is why I funded https://docs.stablebuild.com/ https://docs.stablebuild.com/ some years ago. It lets you pin stuff in dockerfiles that are normally unpinnable like OS package repos, docker hub tags and random files on the internet. So you can go back to a project a year from now and actually get the same container back again.
  - jselysianeagle 1y ago
    Isn't this problem usually solved by building an actual image for your specific application, tagging that and pushing to some docker repo? At least that's how it's been at placec I've worked at that used docker. What am I missing?
    - jamwil 1y ago
      Perhaps more focused on docker-based development workflows than final deployment.
    - fcarraldo 1y ago
      Builds typically aren’t retained forever.
    - lmm 1y ago
      What do you do when you then actually need to make a change to your application (e.g. a 1-liner fix)? Edit the binary image?
      - xylophile 1y ago
        You can always edit the file in the container and re-upload it with a different tag. That's not best practice, but it's not exactly sorcery.
        lmm 1y ago
        It's not, but at that point you're giving up on most of the things Docker was supposed to get you. What about when you need to upgrade a library dependency (but not all of them, just that one)?
        jselysianeagle 1y ago
        I'm not sure what the complication here is. If application code changes, or some dependency changes, you build a new docker image as needed, possibly with an updated Dockerfile as well if that's required. The Dockerfile is part of the application repo and versioned just like everything else in the repo. CICD helps build and push a new image during PRs, or tag creation, just like you would with any application package / artifact. Frequent building and pushing of docker images can over time start taking up space of course but you can take care of that by maybe cleaning out old images from time to time if you can determine they're no longer needed.
      - 1y ago
- northzen 1y ago
  Use pixi or uv to maintain this specific environment and separate it from the global one
- sroerick 1y ago
  I know this pain, and Docker absolutely makes sense for this use case, but I feel like we would both agree that this is a duct tape and bubble gum solution? Though a totally justifiable one
  - Shog9 1y ago
    Oh sure. 20 years ago I used VMs and that was also a duct tape solution. I'd have hoped for a proper solution by now, but a lighter hack works too
roozbeh18 1y ago
Someone wrote a PHP7 script to generate some of our daily reports a while back that nobody wants to touch. Docker happily runs the PHP7 code in the container and generates the reports on any system. its portable, and it doesnt require upkeep.
bolobo 1y ago
> I genuinely don't understand what docker brings to the table. I mean, I get the value prop. But it's really not that hard to set up http on vanilla Ubuntu (or God forbid, OpenBSD) and not really have issues. For me, as an ex-ops, the value proposition is to be able to package a complex stack made of one or more db, several services and tools (ours and external), + describe the interface of these services with the system in a standard way (env vars + mounts points). It massively simplify the onboarding experience, make updating the stack trivial, and also allow devs, ci and prod to run the same version of all the libraries and services.
- sroerick 1y ago
  OK, I completely agree with this. That said, I'm not a nix guy, but to me, intuitively NixOS wins for this use case. It seems like you could either A. Use declarative OS installs across deployments B. Put your app into a container which sometimes deploys it's own kernel and then sometimes doesn't and this gets pushed to a third party cloud registry, or you can set up your own registry, and then this container runs on a random ubuntu container or cloud hosting site where you basically don't administer or do any ops you just kind of use it as an empty vessel which exists to run your Docker container. I get that in practice, these are basically the same, and I think that's a testament to the massive infrastructure work Docker, Inc has done. But it just doesn't make any sense to me
  - sterlind 1y ago
    you can actually declare containers directly in Nix. they use the same config/services/packages machinery as you'd use to declare a system config. and then you can embed them in the parent machine's config, so they all come online and talk to each other with the right endpoints and volumes and such. or you can use the `build(Layered)Image` to declaratively build an oci image with whatever inside it. I think you can mix and match the approaches. but yes I'm personally a big fan of Nix's solution to the "works on my machine" problem. all the reproducibility without the clunkiness of having to shell into a special dev container, particularly great for packaging custom tools or weird compilers or other finnicky things that you want to use, not serve.
  - 1y ago
IanCal 1y ago
Managing and running some containers is really easy though. And running daemons? Don’t we all have loads of things running all the time? I find it easier to have the same interface for everything, where I can easily swap around ports.
rcv 1y ago
> I genuinely don't understand what docker brings to the table. I mean, I get the value prop. But it's really not that hard to set up http on vanilla Ubuntu (or God forbid, OpenBSD) and not really have issues. Sounds great if you're only running a single web server or whatever. My team builds a fairly complex system that's comprised of ~45 unique services. Those services are managed by different teams with slightly different language/library/etc needs and preferences. Before we containerized everything it was a nightmare keeping everything in sync and making sure different teams didn't step on each others dependencies. Some languages have good tooling to help here (e.g. Python virtual environments) but it's not so great if two services require a different version of Boost. With Docker, each team is just responsible for making sure their own containers build and run. Use whatever you need to get your job done. Our containers get built in CI, so there is basically a zero percent chance I'll come in in the morning and not be able to run the latest head of develop because someone else's dev machine is slightly different from mine. And if it runs on my machine, I have very good confidence it will run on production.
- const_cast 1y ago
  [flagged]
  - Bnjoroge 1y ago
    what they described is a fairly common set up in damn near most enterprises
    - nazgul17 1y ago
      Both can be true
    - sroerick 1y ago
      Wherefore art thou IBM
    - fulafel 1y ago
      Enterprises are frequently antipattern zoos. If you have many teams you can use the modular monolith pattern instead of microservices, that way you have the separation but not the distributed system.
throwmeaway222 1y ago
> I didn't have a clue what I was doing and had to phone a friend. > I genuinely don't understand what docker brings to the table. I think you invalidated your own opinion here
- sroerick 1y ago
  Sorry, sir, I didn't realize nobody should ever spend any time learning anything or, failing that, describe what happened to them during that time. I'm no neckbeard savant but I do have a dozen years of deploying web apps and also using Docker during that time, so I think I'm allowed to have an opinion. Go drink some warm milk, you will feel better.
  - throwmeaway222 1y ago
    You have 12 years of deployment experience and some of that using docker, would have been a more useful thing to say in your OC. I was literally just pointing out your argument was pretty weak - this context would have made it stronger.
bonzini 1y ago
QEMU used a similar CI for its website before switching to Gitlab pages: https://gist.github.com/bonzini/1abbbdec739e77503945a3605e0e6442 https://gist.github.com/bonzini/1abbbdec739e77503945a3605e0e...
ownagefool 1y ago
Forget docker for a second. Suddenly you're in a team with 2-3 people and one of them likes to git push broken code and walk-off. Okay, lets make this less about working with a jack-ass, same setup, but each 5 minutes of downtime cost you millions of dollars. One of your pushes work locally but don't work on the server. The point of a more structed / complex CI/CD process is to eliminate failures. As the stakes become higher, and the stack becomes more complex, the need for the automation grows. Docker is just a single part of that automation that makes other things / possible / lowers specific class of failures.
tasuki 1y ago
> We set up a git post receive hook which built static files and restarted httpd on a git receive. Deployment was just 'git push live master'. I still do that for all my personal projects! One of the advantages of docker is that you don't have to rebuild the thing on each deployment target.
antihero 1y ago
> Is the reproducibility of docker really worth the added overhead of managing containers, docker compose, and running daemons on your devbox 24/7? Yes. Everything on my box is ephemeral and can be deleted and recreated or put on another box with little-to-no thought. Infrastructure-as-code means my setup is immutable and self-documented. It's a little more time to set up initially, but now I know exactly what is running. I don't really understand the 24/7 comment, now that it is set up there's very very little maintenance. Sometimes an upgrade might go askew but that is rare. Any change to it is recorded as a git commit, I don't have to worry about logging what I've done ever because it's done for me. Changes are handled by a GitHub action, all I have to do to change what is running is commit a file, and the infra will update itself. I don't use docker-compose, I use a low-overhead microk8s single-node cluster that I don't think about at all really, I just have changes pushed to it directly with Pulumi (in a real environment I'd use something like ArgoCD) and everything just works nicely. Ingress to services is done through Cloudflare tunnels so I don't even have to port-forward or think about NAT or anything like this. To update my personal site, I just do a git commit/push, the it's CI/CD builds builds a container and then updates the Pulumi config in the other repo to point to the latest hash, which then kicks off an action in my infra repo to do a Pulumi apply. Currently it runs on Ubuntu but I'm thinking of using Talos (though it's still nice to be able to just SSH to the box and mess around with files). I'm not sure why people struggle with this, or the benefits of this approach, so much? It seems like a lot of complexity if you're inexperienced, but if you've been working with computers for a long time, it isn't particularly difficult—there are far more complicated things that computers do. I could throw the box (old macbook) in a lake and be up and running with every service on a new box in an hour or so. Or I could run it on the cloud. Or a VPS, or metal, or whatever really, it's a completely portable setup.
strzibny 1y ago
I know well what you are talking about since I did something similar, but I finally moved to Docker with Kamal (except one project I still have to move). The advantage of Docker's reproducibility is to have a peace of mind when comes to rollbacks and running exact versions due to system dependencies. If anyone is curious I wrote Kamal Handbook to help people adopt Kamal which I think brings all the niceness to Docker deployment so it's not annoying.
ctkhn 1y ago
Just for my home server, I have more than 10 containers for home assistant, vpn, library management for movies/tv/music, photos backup, password manager, and a notes server. I started without knowing what docker was, and in less than a year realized running services directly on my OS was more hassle than I wanted both with compatibility between services dependencies, networking setup for them, and configuring reboots and upgrades. I would say the reproducibility and configurability is easily worth the slight overhead and in my experience even reduced it.
kqr 1y ago
Docker in and of itself does not do you much good. Its strength comes from the massive amounts of generic tooling that is built around the container as the standard deployable unit. If you want to handle all your deployments the same way, you can basically only choose between Nix and containers. Unfortunately, containers are far more popular and have more tooling.
- sroerick 1y ago
  I think this is accurate. It just feels like a lot of "we use Docker because everybody uses Docker. That's just the way we do it. But if you actually add up the time we spend using docker, I'm really not sure it saves that many cycles
twelvedogs 1y ago
> Is the reproducibility of docker really worth the added overhead of managing containers, docker compose, and running daemons on your devbox 24/7? Why wouldn't it be, containers are super easy to manage, dockerd uses bugger all resources in dev (on Linux anyway) and docker compose files are the simplest setup scripts I've ever used I like docker because it's easy and I'm lazy
rollcat 1y ago
> God forbid, OpenBSD What exactly is your problem with OpenBSD? Shaming it completely out of context is kinda mean - they're the upstream for OpenSSH and LibreSSL.

Shog9 1y ago

Reproducibility? No. Not having to regularly rebuild the whole dev environment because I need to work on one particular Python app once a quarter and its build chain reliably breaks other stuff? Priceless.

janjongboom 1y ago
This false sense of reproducability is why I funded https://docs.stablebuild.com/ https://docs.stablebuild.com/ some years ago. It lets you pin stuff in dockerfiles that are normally unpinnable like OS package repos, docker hub tags and random files on the internet. So you can go back to a project a year from now and actually get the same container back again.
- jselysianeagle 1y ago
  Isn't this problem usually solved by building an actual image for your specific application, tagging that and pushing to some docker repo? At least that's how it's been at placec I've worked at that used docker. What am I missing?
  - jamwil 1y ago
    Perhaps more focused on docker-based development workflows than final deployment.
  - fcarraldo 1y ago
    Builds typically aren’t retained forever.
  - lmm 1y ago
    What do you do when you then actually need to make a change to your application (e.g. a 1-liner fix)? Edit the binary image?
    - xylophile 1y ago
      You can always edit the file in the container and re-upload it with a different tag. That's not best practice, but it's not exactly sorcery.
      - lmm 1y ago
        It's not, but at that point you're giving up on most of the things Docker was supposed to get you. What about when you need to upgrade a library dependency (but not all of them, just that one)?
        jselysianeagle 1y ago
        I'm not sure what the complication here is. If application code changes, or some dependency changes, you build a new docker image as needed, possibly with an updated Dockerfile as well if that's required. The Dockerfile is part of the application repo and versioned just like everything else in the repo. CICD helps build and push a new image during PRs, or tag creation, just like you would with any application package / artifact. Frequent building and pushing of docker images can over time start taking up space of course but you can take care of that by maybe cleaning out old images from time to time if you can determine they're no longer needed.
    - 1y ago
northzen 1y ago
Use pixi or uv to maintain this specific environment and separate it from the global one
sroerick 1y ago
I know this pain, and Docker absolutely makes sense for this use case, but I feel like we would both agree that this is a duct tape and bubble gum solution? Though a totally justifiable one
- Shog9 1y ago
  Oh sure. 20 years ago I used VMs and that was also a duct tape solution. I'd have hoped for a proper solution by now, but a lighter hack works too

roozbeh18 1y ago

Someone wrote a PHP7 script to generate some of our daily reports a while back that nobody wants to touch. Docker happily runs the PHP7 code in the container and generates the reports on any system. its portable, and it doesnt require upkeep.

bolobo 1y ago

> I genuinely don't understand what docker brings to the table. I mean, I get the value prop. But it's really not that hard to set up http on vanilla Ubuntu (or God forbid, OpenBSD) and not really have issues. For me, as an ex-ops, the value proposition is to be able to package a complex stack made of one or more db, several services and tools (ours and external), + describe the interface of these services with the system in a standard way (env vars + mounts points). It massively simplify the onboarding experience, make updating the stack trivial, and also allow devs, ci and prod to run the same version of all the libraries and services.

sroerick 1y ago
OK, I completely agree with this. That said, I'm not a nix guy, but to me, intuitively NixOS wins for this use case. It seems like you could either A. Use declarative OS installs across deployments B. Put your app into a container which sometimes deploys it's own kernel and then sometimes doesn't and this gets pushed to a third party cloud registry, or you can set up your own registry, and then this container runs on a random ubuntu container or cloud hosting site where you basically don't administer or do any ops you just kind of use it as an empty vessel which exists to run your Docker container. I get that in practice, these are basically the same, and I think that's a testament to the massive infrastructure work Docker, Inc has done. But it just doesn't make any sense to me
- sterlind 1y ago
  you can actually declare containers directly in Nix. they use the same config/services/packages machinery as you'd use to declare a system config. and then you can embed them in the parent machine's config, so they all come online and talk to each other with the right endpoints and volumes and such. or you can use the `build(Layered)Image` to declaratively build an oci image with whatever inside it. I think you can mix and match the approaches. but yes I'm personally a big fan of Nix's solution to the "works on my machine" problem. all the reproducibility without the clunkiness of having to shell into a special dev container, particularly great for packaging custom tools or weird compilers or other finnicky things that you want to use, not serve.
- 1y ago

IanCal 1y ago

Managing and running some containers is really easy though. And running daemons? Don’t we all have loads of things running all the time? I find it easier to have the same interface for everything, where I can easily swap around ports.

rcv 1y ago

> I genuinely don't understand what docker brings to the table. I mean, I get the value prop. But it's really not that hard to set up http on vanilla Ubuntu (or God forbid, OpenBSD) and not really have issues. Sounds great if you're only running a single web server or whatever. My team builds a fairly complex system that's comprised of ~45 unique services. Those services are managed by different teams with slightly different language/library/etc needs and preferences. Before we containerized everything it was a nightmare keeping everything in sync and making sure different teams didn't step on each others dependencies. Some languages have good tooling to help here (e.g. Python virtual environments) but it's not so great if two services require a different version of Boost. With Docker, each team is just responsible for making sure their own containers build and run. Use whatever you need to get your job done. Our containers get built in CI, so there is basically a zero percent chance I'll come in in the morning and not be able to run the latest head of develop because someone else's dev machine is slightly different from mine. And if it runs on my machine, I have very good confidence it will run on production.

const_cast 1y ago
[flagged]
- Bnjoroge 1y ago
  what they described is a fairly common set up in damn near most enterprises
  - nazgul17 1y ago
    Both can be true
  - sroerick 1y ago
    Wherefore art thou IBM
  - fulafel 1y ago
    Enterprises are frequently antipattern zoos. If you have many teams you can use the modular monolith pattern instead of microservices, that way you have the separation but not the distributed system.

throwmeaway222 1y ago

> I didn't have a clue what I was doing and had to phone a friend. > I genuinely don't understand what docker brings to the table. I think you invalidated your own opinion here

sroerick 1y ago
Sorry, sir, I didn't realize nobody should ever spend any time learning anything or, failing that, describe what happened to them during that time. I'm no neckbeard savant but I do have a dozen years of deploying web apps and also using Docker during that time, so I think I'm allowed to have an opinion. Go drink some warm milk, you will feel better.
- throwmeaway222 1y ago
  You have 12 years of deployment experience and some of that using docker, would have been a more useful thing to say in your OC. I was literally just pointing out your argument was pretty weak - this context would have made it stronger.

bonzini 1y ago

QEMU used a similar CI for its website before switching to Gitlab pages: https://gist.github.com/bonzini/1abbbdec739e77503945a3605e0e6442 https://gist.github.com/bonzini/1abbbdec739e77503945a3605e0e...

ownagefool 1y ago

Forget docker for a second. Suddenly you're in a team with 2-3 people and one of them likes to git push broken code and walk-off. Okay, lets make this less about working with a jack-ass, same setup, but each 5 minutes of downtime cost you millions of dollars. One of your pushes work locally but don't work on the server. The point of a more structed / complex CI/CD process is to eliminate failures. As the stakes become higher, and the stack becomes more complex, the need for the automation grows. Docker is just a single part of that automation that makes other things / possible / lowers specific class of failures.

tasuki 1y ago

> We set up a git post receive hook which built static files and restarted httpd on a git receive. Deployment was just 'git push live master'. I still do that for all my personal projects! One of the advantages of docker is that you don't have to rebuild the thing on each deployment target.

antihero 1y ago

> Is the reproducibility of docker really worth the added overhead of managing containers, docker compose, and running daemons on your devbox 24/7? Yes. Everything on my box is ephemeral and can be deleted and recreated or put on another box with little-to-no thought. Infrastructure-as-code means my setup is immutable and self-documented. It's a little more time to set up initially, but now I know exactly what is running. I don't really understand the 24/7 comment, now that it is set up there's very very little maintenance. Sometimes an upgrade might go askew but that is rare. Any change to it is recorded as a git commit, I don't have to worry about logging what I've done ever because it's done for me. Changes are handled by a GitHub action, all I have to do to change what is running is commit a file, and the infra will update itself. I don't use docker-compose, I use a low-overhead microk8s single-node cluster that I don't think about at all really, I just have changes pushed to it directly with Pulumi (in a real environment I'd use something like ArgoCD) and everything just works nicely. Ingress to services is done through Cloudflare tunnels so I don't even have to port-forward or think about NAT or anything like this. To update my personal site, I just do a git commit/push, the it's CI/CD builds builds a container and then updates the Pulumi config in the other repo to point to the latest hash, which then kicks off an action in my infra repo to do a Pulumi apply. Currently it runs on Ubuntu but I'm thinking of using Talos (though it's still nice to be able to just SSH to the box and mess around with files). I'm not sure why people struggle with this, or the benefits of this approach, so much? It seems like a lot of complexity if you're inexperienced, but if you've been working with computers for a long time, it isn't particularly difficult—there are far more complicated things that computers do. I could throw the box (old macbook) in a lake and be up and running with every service on a new box in an hour or so. Or I could run it on the cloud. Or a VPS, or metal, or whatever really, it's a completely portable setup.

strzibny 1y ago

I know well what you are talking about since I did something similar, but I finally moved to Docker with Kamal (except one project I still have to move). The advantage of Docker's reproducibility is to have a peace of mind when comes to rollbacks and running exact versions due to system dependencies. If anyone is curious I wrote Kamal Handbook to help people adopt Kamal which I think brings all the niceness to Docker deployment so it's not annoying.

ctkhn 1y ago

Just for my home server, I have more than 10 containers for home assistant, vpn, library management for movies/tv/music, photos backup, password manager, and a notes server. I started without knowing what docker was, and in less than a year realized running services directly on my OS was more hassle than I wanted both with compatibility between services dependencies, networking setup for them, and configuring reboots and upgrades. I would say the reproducibility and configurability is easily worth the slight overhead and in my experience even reduced it.

kqr 1y ago

Docker in and of itself does not do you much good. Its strength comes from the massive amounts of generic tooling that is built around the container as the standard deployable unit. If you want to handle all your deployments the same way, you can basically only choose between Nix and containers. Unfortunately, containers are far more popular and have more tooling.

sroerick 1y ago
I think this is accurate. It just feels like a lot of "we use Docker because everybody uses Docker. That's just the way we do it. But if you actually add up the time we spend using docker, I'm really not sure it saves that many cycles

twelvedogs 1y ago

> Is the reproducibility of docker really worth the added overhead of managing containers, docker compose, and running daemons on your devbox 24/7? Why wouldn't it be, containers are super easy to manage, dockerd uses bugger all resources in dev (on Linux anyway) and docker compose files are the simplest setup scripts I've ever used I like docker because it's easy and I'm lazy

rollcat 1y ago

> God forbid, OpenBSD What exactly is your problem with OpenBSD? Shaming it completely out of context is kinda mean - they're the upstream for OpenSSH and LibreSSL.