4 ms·

How do you debug (in dev or prod), or in production, do things such as inspecting log files, monitoring system resources, running necessary commands if there is

How do you debug (in dev or prod), or in production, do things such as inspecting log files, monitoring system resources, running necessary commands if there is something urgent...? In my experience, Docker just makes everything more tedious without tangible benefits. I personally lose nothing by not using Docker and am much faster in everything I do.

piaste 6y ago
> How do you debug (in dev or prod) VSCode lets you debug inside a Docker container. > or in production, do things such as inspecting log files Logs should be sent out of the container, either directly (mount a /logs folder, push them to Sentry / ELK / etc.) or by simply logging to stdout and having Docker send the logs where you want. > monitoring system resources Docker processes are still processes. They show up in `top` and friends just fine. > running necessary commands if there is something urgent...? `Docker exec my_container <insert command here>`. Although I've never even considered doing that. For the past few years the resolution to a production bug has always been "rollback to the previous image, then if any data got borked fix it in the database".
- mherrmann 6y ago
  Everything you write is possible, but - and again in every single step of your daily dev work - more tedious than doing things directly. It's just not worth it for me. But it also sounds like you are operating within a larger organization. So your requirements may be different from mine.
  - nwmcsween 6y ago
    Because it codifies things and ensures people don't make a giant mess of intertwined crap that takes days/months to separate due to random global dependencies such as a cron/script/mount/etc.
  - emptysongglass 6y ago
    It's not tedious at all and it saves potentially blowing up your system with crap splattered all over your filesystem. We have tons of WSL2 devs and Linux people and it takes care of the, "it works on my machine" problem once and for all. This insistent push that the old way was good and why did we expend all this effort to make a new thing that I don't want to bother learning the five new invocations to just doesn't line up with the needs of today. Docker pull, docker exec, docker ps, docker logs and you've pretty much got what you need for ninety percent of your job. This stuff is not hard. You make it hard for yourself by digging in.
    - mherrmann 6y ago
      (Edited to remove a snarky comment I made.) "New is good" is also no general justification. It always depends on the context. Several replies in this thread mention very good use cases where Docker makes sense. From what you wrote, it sounds to me like it also makes sense in your environment. Yes I mean I don't want to have to learn things that don't bring me value. But it's not about learning the commands. It's about having to repeat them over and over again in my daily work. About the associated mental burden "am I in the container now? Is it running?" And about everything taking longer, be it running tests in Docker or pushing to a registry and waiting for the new container to be spawned. As a single dev, and I feel this is where your and my requirements differ, it simply is not worth it.
    - treekogreen 6y ago
      I echo this sentiment entirely.. mutli dev-environment, multi-machine / os things really just work. Docker et al also really shines with onboarding, the new recruit can literally get up and going in minutes. I would not want to go back to the old ways of doing things.
- adgud 6y ago
  > VSCode lets you debug inside a Docker container. Can you connect to a remote host that runs the container? Docker exec won't work if the container spins into start/fail loop.
kristiandupont 6y ago
How much experience do you have with Docker? I am not being snarky -- all the things you say sounds like something I would have said until I pulled myself together and learned how to use it properly. And granted, that did take a bit of effort but now my perspective is that Docker is extraordinarily easy to work with. A Dockerfile is almost exactly like your requirements.txt file, only it works for everything. Need Imagemagick installed on your server? Just add it to the Dockerfile. Need to run a pre-start tool that was written in Ruby? A line or two in the Dockerfile can add that. And if it turns out that you don't want it after all, you just remove the lines and feel confident that no trace is left behind.
- mherrmann 6y ago
  I don't have a lot of experience with Docker, but it's not what's holding me back. Here are some of my pain points: 1) Having to "docker exec" to get a shell in a running container vs just running the command (in dev) or sshing into the server (in prod). 2) Tests taking 3:30 min to run with docker vs 30 secs without. And then of course, you don't just run tests once but many times, leading to tens of minutes on a given day where I'm just twisting my thumbs. 3) Having to even spend time learning how to debug Python code inside a locally running docker container. 4) Having to deal with disk space issues caused by old docker images on my 500gb hdd. All while not deriving any value from it in my projects.
  - neurostimulant 6y ago
    > Having to "docker exec" to get a shell in a running container vs just running the command (in dev) or sshing into the server (in prod). If this bother you, take a look at some 3rd party docker management ui such as portainer (vanilla docker) or k9s (kubernetes). These tools will let you navigate and launch shell on your container quickly. Very useful if you have tons of apps running in your node. > Tests taking 3:30 min to run with docker vs 30 secs without. And then of course, you don't just run tests once but many times, leading to tens of minutes on a given day where I'm just twisting my thumbs. In my case, I don't use docker in development phase. I test in local environment and only build the images when it's ready for deployment. > Having to even spend time learning how to debug Python code inside a locally running docker container. I never had to do this anymore. I just hook sentry or newrelic and they'll log exception stack traces that I can use to figure out the issue without live-debugging the app. > Having to deal with disk space issues caused by old docker images on my 500gb hdd. Yes, disk usage is one of the drawback of using docker. It's especially suck pruning images on busy servers with spinning rust. On ssd, pruning is not as slow though.

piaste 6y ago

> How do you debug (in dev or prod) VSCode lets you debug inside a Docker container. > or in production, do things such as inspecting log files Logs should be sent out of the container, either directly (mount a /logs folder, push them to Sentry / ELK / etc.) or by simply logging to stdout and having Docker send the logs where you want. > monitoring system resources Docker processes are still processes. They show up in `top` and friends just fine. > running necessary commands if there is something urgent...? `Docker exec my_container <insert command here>`. Although I've never even considered doing that. For the past few years the resolution to a production bug has always been "rollback to the previous image, then if any data got borked fix it in the database".

mherrmann 6y ago
Everything you write is possible, but - and again in every single step of your daily dev work - more tedious than doing things directly. It's just not worth it for me. But it also sounds like you are operating within a larger organization. So your requirements may be different from mine.
- nwmcsween 6y ago
  Because it codifies things and ensures people don't make a giant mess of intertwined crap that takes days/months to separate due to random global dependencies such as a cron/script/mount/etc.
- emptysongglass 6y ago
  It's not tedious at all and it saves potentially blowing up your system with crap splattered all over your filesystem. We have tons of WSL2 devs and Linux people and it takes care of the, "it works on my machine" problem once and for all. This insistent push that the old way was good and why did we expend all this effort to make a new thing that I don't want to bother learning the five new invocations to just doesn't line up with the needs of today. Docker pull, docker exec, docker ps, docker logs and you've pretty much got what you need for ninety percent of your job. This stuff is not hard. You make it hard for yourself by digging in.
  - mherrmann 6y ago
    (Edited to remove a snarky comment I made.) "New is good" is also no general justification. It always depends on the context. Several replies in this thread mention very good use cases where Docker makes sense. From what you wrote, it sounds to me like it also makes sense in your environment. Yes I mean I don't want to have to learn things that don't bring me value. But it's not about learning the commands. It's about having to repeat them over and over again in my daily work. About the associated mental burden "am I in the container now? Is it running?" And about everything taking longer, be it running tests in Docker or pushing to a registry and waiting for the new container to be spawned. As a single dev, and I feel this is where your and my requirements differ, it simply is not worth it.
  - treekogreen 6y ago
    I echo this sentiment entirely.. mutli dev-environment, multi-machine / os things really just work. Docker et al also really shines with onboarding, the new recruit can literally get up and going in minutes. I would not want to go back to the old ways of doing things.
adgud 6y ago
> VSCode lets you debug inside a Docker container. Can you connect to a remote host that runs the container? Docker exec won't work if the container spins into start/fail loop.

kristiandupont 6y ago

How much experience do you have with Docker? I am not being snarky -- all the things you say sounds like something I would have said until I pulled myself together and learned how to use it properly. And granted, that did take a bit of effort but now my perspective is that Docker is extraordinarily easy to work with. A Dockerfile is almost exactly like your requirements.txt file, only it works for everything. Need Imagemagick installed on your server? Just add it to the Dockerfile. Need to run a pre-start tool that was written in Ruby? A line or two in the Dockerfile can add that. And if it turns out that you don't want it after all, you just remove the lines and feel confident that no trace is left behind.

mherrmann 6y ago
I don't have a lot of experience with Docker, but it's not what's holding me back. Here are some of my pain points: 1) Having to "docker exec" to get a shell in a running container vs just running the command (in dev) or sshing into the server (in prod). 2) Tests taking 3:30 min to run with docker vs 30 secs without. And then of course, you don't just run tests once but many times, leading to tens of minutes on a given day where I'm just twisting my thumbs. 3) Having to even spend time learning how to debug Python code inside a locally running docker container. 4) Having to deal with disk space issues caused by old docker images on my 500gb hdd. All while not deriving any value from it in my projects.
- neurostimulant 6y ago
  > Having to "docker exec" to get a shell in a running container vs just running the command (in dev) or sshing into the server (in prod). If this bother you, take a look at some 3rd party docker management ui such as portainer (vanilla docker) or k9s (kubernetes). These tools will let you navigate and launch shell on your container quickly. Very useful if you have tons of apps running in your node. > Tests taking 3:30 min to run with docker vs 30 secs without. And then of course, you don't just run tests once but many times, leading to tens of minutes on a given day where I'm just twisting my thumbs. In my case, I don't use docker in development phase. I test in local environment and only build the images when it's ready for deployment. > Having to even spend time learning how to debug Python code inside a locally running docker container. I never had to do this anymore. I just hook sentry or newrelic and they'll log exception stack traces that I can use to figure out the issue without live-debugging the app. > Having to deal with disk space issues caused by old docker images on my 500gb hdd. Yes, disk usage is one of the drawback of using docker. It's especially suck pruning images on busy servers with spinning rust. On ssd, pruning is not as slow though.