Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • Surprised they didn't mention docker compose secrets - https://docs.docker.com/reference/compose-file/secrets/
    by meander_water
  • To be honest I never really understood the benefit of Docker (Compose) Secrets - which is different from Swarm Secrets. Imho there just plain host mounted volumes, which are hidden from inspect commands?
    by pmig
  • I am using systemd + go binary deploy. Running 10 years+ in production. Meanwhile docker based setup fail every now and then. And kubernetes? well forget about it.
    by faangguyindia
  • Do you do rolling deploys?
    by davidatbu
  • How does this work? Can you show it?
    by vincentkriek
  • What I'd like is systemd-compose. Maintaining several dozens of .service-files is not my idea of fun.
    by marginalia_nu
  • That's like comparing you being able to make a salad from tomatoes and an industrial tomato sauce making facility. Both take tomatoes and end up with food, but the scale is completely different.

    Yes, you can deploy a Go binary easily with systemd. Could you reliably do this across a fleet of machines? Including managing its configuration, persistent storage, database, network setup, etc.? Maybe, just need Ansible or equivalent config management. What if it were multiple Go binaries? And what if some of them needed to scale up some days because they hit more traffic than the others?

    And on and on. Yes, not everyone needs Kubernetes, Nomad or other advanced orchestrators. But comparing them to running a Go binary with systemd is an unfair comparison.

    by sofixa
  • I am using docker-compose everywhere. I really enjoy using it. I have a single thing that is annoying for normal production deployments, and that is that it isn't super easy to have a rolling deployment, I just need two replicas for zero downtime deployment, and I don't really want docker swarm. I think it is the networking which breaks at that point, and you have to have a more involved setup, and at that point I'd just use kubernetes, as I know how that works.

    Could i survive with 10 seconds of downtime, probably, but I'd really like if I could avoid it.

    by kjuulh
  • this is a hack I have used and am proud of:

    if you use Caddy as your reverse proxy (instead of nginx for example which does not do this), when requests come in and your service is missing because it's being deployed, Caddy waits for a timeout before giving up. this means that visitors during the brief deploy period don't see errors - they just get a slightly longer wait, which often is not obvious depending on how long your service takes to boot.

    by crummy
  • Why not use swarm? On a single node it isn't really more complicated than compose, and you get scaling and rolling deployments.
    by n_e
  • Reading the article over, it really feels like Docker should be targeting Swarm as (instead of being its own platform) a set of incremental enhancements to Docker Compose. "I need healthcheck-restarts" "I need off-host logging", etc.

    They've basically lost the war against Kubernetes but they could easily claim a lot of ground when it's just one more tweak you're adding to your docker-compose file as it scales.

    by Pxtl
  • I’m happily taking that 10sec whenever thinking about the lifting I have to do for kube and extra cost.
    by jimmydoe
  • That's why I now use uncloud, simple as docker compose and got rolling deployments

    https://uncloud.run/docs/guides/deployments/rolling-deployme...

    by derfurth
  • What I found pretty great with docker is isolating individual docker systemd instances in rootless linux namespaces (i.e. users). I wrote about this here [1]. This lets you easily create multiple services on one VM that are quite isolated from each other. This system of doing things has worked reliably for me for quite some time, even for the 'bigger' services (gitlab, nextcloud, mailcow-dockerized etc.).

    [1]: https://du.nkel.dev/blog/2023-12-12_mastodon-docker-rootless...

    by Helmut10001
  • What a great blog post! I have wanted to do rootless docker with subuids, but putting it all together like you have is not easy. Thank you for writing it down!
    by larsnystrom
  • Compose is great, but a couple things always created friction for me when using it for non-local setups:

    * Lack of a user-friendly way of managing a Docker Compose installation on a remote host. SSH-forwarding the docker socket is an option, but needs wrappers and discipline.

    * Growing beyond one host (and not switching to something like Kubernetes) would normally mean migrating to Swarm, which is its own can of worms.

    * Boilerplate needed to expose your services with TLS

    Uncloud [1] fixed all those issues for me and is (mostly) Compose-compatible.

    [1] https://github.com/psviderski/uncloud/

    by tontony
  • > Lack of a user-friendly way of managing a Docker Compose installation on a remote host

    I've been using portainer for years, it's decent.

    by esperent
  • For remote installation, use the `docker context` command. You create a context with a named SSH host and then it connects via SSH to that host (as configured in your local ssh_config) and uses its docker daemon. Everything works flawlessly apart from local bind mounts (for obvious reasons).

    If you remember `docker machine`, this is basically the modern version of that.

    by chatmasta
  • I really want something that is Docker Compose but for Kubernetes. I mean that I can have a simple way to declaring resources in just like Docker Compose, but I run the environment in Kubernetes so that I can get to test the behaviors when there are multiple copies of the softwares running together. I do rely on Kubernetes heavily for distributed and networked software deployment, so it is even better if we can emulate things like latency or burstable packet loss so that we can do a controlled chaos test for reliability test. I tried Skaffold, Tilt, Devspaces and Devpod/Coder v2, none of them are really simple like Compose.
    by stevefan1999
  • You should take a look at https://nixidy.dev/.
    by mehackernewsacc
  • This is a great idea for some vibe coding tbh and you can customize it to match exactly the resources that you need as everyone has slightly different requirements for their k8s stack.

    The simplest way to start probably would just be to create a custom Helm chart and define what you want in `values.yaml`.

    by suralind
  • Have you looked into some of the Docker Compose Bridge transformers? We’re using it to scaffold out k8s apps for UDS from compose files https://github.com/defenseunicorns-labs/compose-bridge-uds/
    by willswire
  • Helm mostly does that. Not a huge fan of a text templating engine generating yaml but once you get your chart setup with a few variable inputs, you can continue using it for a bunch of other stuff with minimal new config.

    The inputs (values) are yaml so you can make it look exactly like a Docker Compose file if you want (wouldn't be surprised if there's some charts floating around that do that)

    by nijave
  • This is a problem we, as a company, have thought about a lot, but we always concluded that Kubernetes is already the simplest abstraction of a distributed system that is feasible for the diverse needs that the biggest companies out there have.

    We previously built a package manager for Kubernetes to abstract it in the simplest way possible `glasskube install app` but we failed because every abstraction needs to follow a "convention over configuration" pattern at some point. Also, we weren't able to monetize a package manager.

    With Distr (https://github.com/distr-sh/distr), we have actually been able to help companies not only package but distribute and either manage or give their customers a way to self-manage applications. Our customers are able to land on-premises contracts at enterprises way faster than before, which is also a clear ROI for paying for Distr.

    So, I don't think that you can get the flexibility of a distributed application orchestrator with a simple declarative YAML file if your target environments are diverse.

    by pmig
  • I like running docker compose for my simple needs because it consolidates pretty much all the config in one declarative file, and docker manages 'everything'. By now I know how to handle the handful of caveats listed in this article. Beyond what's listed there, I'd also give a mention to the way port publishing works (the fact that it ignores firewalls), as that's something that still trips people up if they don't know about it.

    > docker compose pull && docker compose up -d is a fine command if you are SSH’d into the host. At customer scale—dozens of self-managed environments behind firewalls, each with its own change-control process—that manual process doesn’t scale.

    No idea what this 'customer scale' operation is, but it seems like a pretty clear cut candidate for not using docker compose. I also don't think watchtower should be listed there, it's been archived and was never recommended for production usage anyways.

    by __jonas
  • Sounds like they're referring to a dedicated tenancy multi-tenant model
    by nijave
  • > I'd also give a mention to the way port publishing works (the fact that it ignores firewalls), as that's something that still trips people up if they don't know about it.

    Isn't that a Docker thing rather than Docker Compose though? There is a ton more caveats to add if we don't already assume the reader is familiar with the hard edges of Docker, seems the article only focuses on Docker Compose specifically, probably because it'd be very long otherwise :)

    by embedding-shape
  • > docker compose pull && docker compose up -d is a fine command if you are SSH’d into the host. At customer scale—dozens of self-managed environments behind firewalls, each with its own change-control process—that manual process doesn’t scale.

    We just use ansible for this part.

    by selfmodruntime
  • How do you guys, who run Docker in production deal with managing nftables firewall on hosts running containers? By design docker daemon creates and manages a set of firewall rules to forward traffic between containers and ingress traffic into containers as well as masquarades the outgoing container traffic. That is all well until admin needs to alter hosts firewall to allow and deny other traffic unrelated to docker - and restarting nftables or even applying new nftables rules usually ( flush ruleset in /etc/nftables.conf ) purges all the docker created rules and effectively breaks everything until docker daemon is restarted and rules re-created. I have partially solved this by using nftables filter chains with different names - admin_input/admin_output and using input hook with negative priority - so that traffic I choose to block is evaluated before docker rules are applied - that feels a bit like hack, but so far is the only way I have found. It is good practice in this day and age to run local firewalls on all hosts with policy deny, so that only traffic explicitly allowed can pass, that can severely limit blast radius during compromise.
    by merpkz
  • firewalld supports docker and handles all of its routing/changes. I've standardized on using it in my environment.
    by papascrubs