6 ms·

Down the road, pulling the binary in a container for deployment is trivial, so I don’t see a downside here. Of course nobody will advocate that scping a binary

Down the road, pulling the binary in a container for deployment is trivial, so I don’t see a downside here. Of course nobody will advocate that scping a binary on each production server for deployment is viable in the long run, but that should not be your primary concern when going through the early phases of a product. Not focusing on docker from the start forces you to have a clean build and runtime software chain, and reduces the amount of magic required (ironically, going to containers was supposed to be the opposite, but many server-side packages are now docker-only because the build and/or runtime requirements are so messed up, e.g. discourse).

jayd16 5y ago
I just don't get it. Docker is just not that hard to set up. It takes a day or two and you get a lot of flexibility you can use down the line. Sure you could convert later, but now you have to move your whole workflow over during a time you're in dire need of the new features instead of casually from the start. Now instead of your artifact history being consistent, its truncated at the point you switched over. I guess I don't understand whats so complicated about docker?
- dijit 5y ago
  Bridge networking, probably. Overlay filesystem performance across distros? Attaching a debugger to a process? Idk. Just some ideas off the top of my head. I don’t think it’s unimaginable to consider how docker is an increase in complexity and understanding.
  - akvadrako 5y ago
    > Bridge networking, probably. You can just use --net=host if you don't like it. > Overlay filesystem performance across distros? I've used docker on several distros and never noticed an issue with this. > Attaching a debugger to a process? This is also not an issue if you don't use bridge networking.
  - trinovantes 5y ago
    Getting VSCode debugger to hook into a process running in a docker container running inside WSL was insanely frustrating. In the end, I stopped using Docker during development and only use it for deploying to staging/production.
    - ahepp 5y ago
      Did you ever find a satisfying solution? I am trying to make more effective use of docker for development and anticipate needing GDB at some point. I imagine one could install GDB in the container and connect to it remotely? Or from the container's shell?
      - trinovantes 5y ago
        I was eventually able to get it to work by digging through a lot of old GitHub issue discussions. Sadly it was so flaky and slow that I just threw out Docker for development after awhile. IIRC, you just need to install gdb when you build your image and use `docker run -it bash` to run any shell commands in your container
      - Groxx 5y ago
        Ignoring VSCode's insanely fragile config for this, any debugger with a remote protocol tends to work. Personally I have better luck manually setting up a headless GDB session and connecting with intellij, but it's also difficult sometimes. Since the remote stuff is sometimes an incredible pain to set up and use, I usually install gdb and just use its CLI in the container. That's usually trivial in comparison, and it's a decent skill to learn regardless since so many debuggers use a similar CLI UX. It's extremely cross-platform and cross-language, so you can just jump on a new thing and be a wizard from day 1.
      - jgalentine007 5y ago
        For node / php and python I just expose the debugger ports in docker, and if I'm running docker in a VM I just forward them over SSH. VSCode connects to the forwarded port easily, but sometimes you have to struggle with workspace / source mapping and other issues (like connecting to child processes).
- laurent123456 5y ago
  This exactly. Docker provides a way to deploy but also to self-document and version control the deployment process, and having the Dockerfile from the starts brings a lot of value. Without this, deployment starts being spread over various bash files with often poor documentation (they’re already mentioning such a script in their article). Then when it becomes too messy, time to write that Dockerfile I guess, except now it’s more complicated than if it had been done from the start.
- Nowado 5y ago
  'Day or two' isn't actually a trivial amount of time.
- Jiejeing 5y ago
  Docker in itself, apart from everything else, is not that hard to setup. But you have to look at the bigger picture here. Maybe the deployment is on "pet servers" and not on-demand, which means if you are a responsible admin and have a nftables config you need to analyze how docker will mess up your rules (or why it is not working). Maybe you don’t want to lose time setting up an artifactory, and a docker registry with proper access controls. Maybe you don’t want to have to focus on the ops side of things until you actually need it. Yes that may mean losing time later when you need it fast, but at the same time this can be done iteratively when things are ramping up. From experience at a previous workplace, using docker as part of your local development process can be a huge PITA, and getting developers to adopt it without grumbling and complaining about it every day is also a hurdle. Given enough computers, you will get weird network errors, some borked modules due to an upgrade, some containers refusing to die, etc… I am not saying it cannot be done, and in the general case docker mostly works without (too many) glitches, but it is always another layer that hinders your productive work. (also, "docker" in production nowadays is mostly a shortcut for k8s, and that is a whole new amount of investment required)
  - deckard1 5y ago
    > (also, "docker" in production nowadays is mostly a shortcut for k8s, and that is a whole new amount of investment required) It didn't help that Docker tied docker compose to swarm and then swarm kinda died. So I'm really scratching my head at the people recommending docker in this thread. I'm assuming they mean K8S but at the same time surely they can't be serious. Today if you need something at the startup/mid range level you're probably looking at Dokku, Caprover, or maybe even nomad. This is still more complexity than scp, of course.
    - jayd16 5y ago
      Its really not hard at all to set up CI/CD into managed k8s on one of the clouds. You can still trivially use docker compose to set up a local dev environment with all the application appliances like the DB or redis or what have you as docker containers. You get turn key environments with a ton of flexibility for what is honestly much less effort than even maintaining the setup documentation for installing the apps directly.
- void_mint 5y ago
  The above post isn't _really_ about Docker, I don't think. Relying on scp to deploy to prod also has nothing to do with Docker inherently. This post is mostly about rejecting any "modern" build and deploy tools in favor of perceived-simplicity. The problem with perceived-simplicity is it's usually not actually that simple, the developer that thought up the idea just inherently understands it. My post above was mostly to highlight that that pereived-simplicity falls apart when you add more devs, or increased code complexity, etc. Using legitimate tools to handle building and deploying has nothing to do with Docker, but the author of this blog post has combined them.

jayd16 5y ago

I just don't get it. Docker is just not that hard to set up. It takes a day or two and you get a lot of flexibility you can use down the line. Sure you could convert later, but now you have to move your whole workflow over during a time you're in dire need of the new features instead of casually from the start. Now instead of your artifact history being consistent, its truncated at the point you switched over. I guess I don't understand whats so complicated about docker?

dijit 5y ago
Bridge networking, probably. Overlay filesystem performance across distros? Attaching a debugger to a process? Idk. Just some ideas off the top of my head. I don’t think it’s unimaginable to consider how docker is an increase in complexity and understanding.
- akvadrako 5y ago
  > Bridge networking, probably. You can just use --net=host if you don't like it. > Overlay filesystem performance across distros? I've used docker on several distros and never noticed an issue with this. > Attaching a debugger to a process? This is also not an issue if you don't use bridge networking.
- trinovantes 5y ago
  Getting VSCode debugger to hook into a process running in a docker container running inside WSL was insanely frustrating. In the end, I stopped using Docker during development and only use it for deploying to staging/production.
  - ahepp 5y ago
    Did you ever find a satisfying solution? I am trying to make more effective use of docker for development and anticipate needing GDB at some point. I imagine one could install GDB in the container and connect to it remotely? Or from the container's shell?
    - trinovantes 5y ago
      I was eventually able to get it to work by digging through a lot of old GitHub issue discussions. Sadly it was so flaky and slow that I just threw out Docker for development after awhile. IIRC, you just need to install gdb when you build your image and use `docker run -it bash` to run any shell commands in your container
    - Groxx 5y ago
      Ignoring VSCode's insanely fragile config for this, any debugger with a remote protocol tends to work. Personally I have better luck manually setting up a headless GDB session and connecting with intellij, but it's also difficult sometimes. Since the remote stuff is sometimes an incredible pain to set up and use, I usually install gdb and just use its CLI in the container. That's usually trivial in comparison, and it's a decent skill to learn regardless since so many debuggers use a similar CLI UX. It's extremely cross-platform and cross-language, so you can just jump on a new thing and be a wizard from day 1.
    - jgalentine007 5y ago
      For node / php and python I just expose the debugger ports in docker, and if I'm running docker in a VM I just forward them over SSH. VSCode connects to the forwarded port easily, but sometimes you have to struggle with workspace / source mapping and other issues (like connecting to child processes).
laurent123456 5y ago
This exactly. Docker provides a way to deploy but also to self-document and version control the deployment process, and having the Dockerfile from the starts brings a lot of value. Without this, deployment starts being spread over various bash files with often poor documentation (they’re already mentioning such a script in their article). Then when it becomes too messy, time to write that Dockerfile I guess, except now it’s more complicated than if it had been done from the start.
Nowado 5y ago
'Day or two' isn't actually a trivial amount of time.
Jiejeing 5y ago
Docker in itself, apart from everything else, is not that hard to setup. But you have to look at the bigger picture here. Maybe the deployment is on "pet servers" and not on-demand, which means if you are a responsible admin and have a nftables config you need to analyze how docker will mess up your rules (or why it is not working). Maybe you don’t want to lose time setting up an artifactory, and a docker registry with proper access controls. Maybe you don’t want to have to focus on the ops side of things until you actually need it. Yes that may mean losing time later when you need it fast, but at the same time this can be done iteratively when things are ramping up. From experience at a previous workplace, using docker as part of your local development process can be a huge PITA, and getting developers to adopt it without grumbling and complaining about it every day is also a hurdle. Given enough computers, you will get weird network errors, some borked modules due to an upgrade, some containers refusing to die, etc… I am not saying it cannot be done, and in the general case docker mostly works without (too many) glitches, but it is always another layer that hinders your productive work. (also, "docker" in production nowadays is mostly a shortcut for k8s, and that is a whole new amount of investment required)
- deckard1 5y ago
  > (also, "docker" in production nowadays is mostly a shortcut for k8s, and that is a whole new amount of investment required) It didn't help that Docker tied docker compose to swarm and then swarm kinda died. So I'm really scratching my head at the people recommending docker in this thread. I'm assuming they mean K8S but at the same time surely they can't be serious. Today if you need something at the startup/mid range level you're probably looking at Dokku, Caprover, or maybe even nomad. This is still more complexity than scp, of course.
  - jayd16 5y ago
    Its really not hard at all to set up CI/CD into managed k8s on one of the clouds. You can still trivially use docker compose to set up a local dev environment with all the application appliances like the DB or redis or what have you as docker containers. You get turn key environments with a ton of flexibility for what is honestly much less effort than even maintaining the setup documentation for installing the apps directly.
void_mint 5y ago
The above post isn't _really_ about Docker, I don't think. Relying on scp to deploy to prod also has nothing to do with Docker inherently. This post is mostly about rejecting any "modern" build and deploy tools in favor of perceived-simplicity. The problem with perceived-simplicity is it's usually not actually that simple, the developer that thought up the idea just inherently understands it. My post above was mostly to highlight that that pereived-simplicity falls apart when you add more devs, or increased code complexity, etc. Using legitimate tools to handle building and deploying has nothing to do with Docker, but the author of this blog post has combined them.