7 ms·

Perhaps because Docker has great stories for deployment. Many of the complexities of deployment are handled for you (writing a systemd unit, managing rollback,

Perhaps because Docker has great stories for deployment. Many of the complexities of deployment are handled for you (writing a systemd unit, managing rollback, etc).

encryptluks2 5y ago
Docker isn't a cache-all for containers. Docker has a pretty terrible deployment story at this point and I forsee in a couple years it will probably be considered legacy compared to Podman/K3d/Local K8s/etc
- jrockway 5y ago
  I think people use the word Docker to mean "produce an OCI-compliant image that a CRI runtime can run".
  - encryptluks2 5y ago
    Podman does the same thing, as well as other tools. Using Docker to refer to something that doesn't use Docker is like saying that your Android Phone is an iPhone.
- fivea 5y ago
  > Docker has a pretty terrible deployment story (...) This is the very first time I ever heard such nonsense. In all companies I've been, Docker is a renowned problem solver, not only for production deplyments but also for local testing environments and deployments. It even shines as a stand-alone barebones clustering solution with Docker swarm mode.
  - ramoz 5y ago
    I’ve honestly not touched docker in years, but all of my prod apps run in docker. So it’d be paradoxical for me to see I don’t need docker, but I really want to.
    - hvidgaard 5y ago
      Docker can be considered a deployment tool. You package your application in an image and run said image. Development and test of that application does not have to be in a docker image.
      - encryptluks2 5y ago
        Nor does deployment. Podman, Rancher, etc all solve those challenges without relying on Docker and with Docker changing their licensing I don't think it will be the de-facto tool in a couple years. There will be others that will replace it.
        hvidgaard 5y ago
        Docker has become synonymous with OCI images, and my comment was exactly in that context (or at least state of mind) - I should have stated that as well.
    - fivea 5y ago
      > So it’d be paradoxical for me to see I don’t need docker, but I really want to. I find it quite amusing that projects that try to position themselves as Docker alternatives end up basing their presentation on how their project can be used just like Docker, down to Docker's choice of command line interface.
rob74 5y ago
Yeah, but for Docker to handle the complexities of deployment, you first need to handle the complexities of Docker. So OP's question is valid: for most Go apps, all you have to do is compile a binary and copy it to the server - no Docker or other paraphernalia required. Of course that may not be so simple due to various reasons, but it helps to keep that possibility in mind...
- dewey 5y ago
  > you first need to handle the complexities of Docker The complexity of Docker is not that big for a Go deployment though, especially if you have all the other bits for orchestrating your Docker containers (for the rest of your stack) already in place. You mostly just copy the binary into a slim image and you are done.
  - ramoz 5y ago
    Agree, and most complexities will occur in enterprise environments when the os/hardware is locked down — which can make something like SQLite “hard” as would any cpu/disk-bound container. However that should be a platform teams job to resolve, not a backend dev.
  - chriswarbo 5y ago
    > You mostly just copy the binary into a slim image and you are done. You don't need docker for that, just 'tar czf my-layer.tar.gz my-dir'. If you want a manifest file, you can get the digest using `sha256sum my-layer.tar.gz`.
- maccard 5y ago
  > all you have to do is compile a binary and copy it to the server Docker does this quite well, and solves a bunch of other problems you're likely to have regardless. One really simple example is "how do you copy it to the server?" Do you have ssh keys for your server on development machines? How do you handle the "Oh I'll just remote in and fix this one X"? It's also _crazily_ easy to get started with, and handle middling amounts of scale. If you're on AWS, Elastic Beanstalk is plug and play. If you're not, DigitalOcean App platform will host it for you, with automated deployments from git for $5/month with basically no configuration needed from you.

Perhaps because Docker has great stories for deployment. Many of the complexities of deployment are handled for you (writing a systemd unit, managing rollback, etc).

encryptluks2 5y ago

Docker isn't a cache-all for containers. Docker has a pretty terrible deployment story at this point and I forsee in a couple years it will probably be considered legacy compared to Podman/K3d/Local K8s/etc

jrockway 5y ago
I think people use the word Docker to mean "produce an OCI-compliant image that a CRI runtime can run".
- encryptluks2 5y ago
  Podman does the same thing, as well as other tools. Using Docker to refer to something that doesn't use Docker is like saying that your Android Phone is an iPhone.
fivea 5y ago
> Docker has a pretty terrible deployment story (...) This is the very first time I ever heard such nonsense. In all companies I've been, Docker is a renowned problem solver, not only for production deplyments but also for local testing environments and deployments. It even shines as a stand-alone barebones clustering solution with Docker swarm mode.
- ramoz 5y ago
  I’ve honestly not touched docker in years, but all of my prod apps run in docker. So it’d be paradoxical for me to see I don’t need docker, but I really want to.
  - hvidgaard 5y ago
    Docker can be considered a deployment tool. You package your application in an image and run said image. Development and test of that application does not have to be in a docker image.
    - encryptluks2 5y ago
      Nor does deployment. Podman, Rancher, etc all solve those challenges without relying on Docker and with Docker changing their licensing I don't think it will be the de-facto tool in a couple years. There will be others that will replace it.
      - hvidgaard 5y ago
        Docker has become synonymous with OCI images, and my comment was exactly in that context (or at least state of mind) - I should have stated that as well.
  - fivea 5y ago
    > So it’d be paradoxical for me to see I don’t need docker, but I really want to. I find it quite amusing that projects that try to position themselves as Docker alternatives end up basing their presentation on how their project can be used just like Docker, down to Docker's choice of command line interface.

rob74 5y ago

Yeah, but for Docker to handle the complexities of deployment, you first need to handle the complexities of Docker. So OP's question is valid: for most Go apps, all you have to do is compile a binary and copy it to the server - no Docker or other paraphernalia required. Of course that may not be so simple due to various reasons, but it helps to keep that possibility in mind...

dewey 5y ago
> you first need to handle the complexities of Docker The complexity of Docker is not that big for a Go deployment though, especially if you have all the other bits for orchestrating your Docker containers (for the rest of your stack) already in place. You mostly just copy the binary into a slim image and you are done.
- ramoz 5y ago
  Agree, and most complexities will occur in enterprise environments when the os/hardware is locked down — which can make something like SQLite “hard” as would any cpu/disk-bound container. However that should be a platform teams job to resolve, not a backend dev.
- chriswarbo 5y ago
  > You mostly just copy the binary into a slim image and you are done. You don't need docker for that, just 'tar czf my-layer.tar.gz my-dir'. If you want a manifest file, you can get the digest using `sha256sum my-layer.tar.gz`.
maccard 5y ago
> all you have to do is compile a binary and copy it to the server Docker does this quite well, and solves a bunch of other problems you're likely to have regardless. One really simple example is "how do you copy it to the server?" Do you have ssh keys for your server on development machines? How do you handle the "Oh I'll just remote in and fix this one X"? It's also _crazily_ easy to get started with, and handle middling amounts of scale. If you're on AWS, Elastic Beanstalk is plug and play. If you're not, DigitalOcean App platform will host it for you, with automated deployments from git for $5/month with basically no configuration needed from you.