4 ms·
I'm running a couple of small servers with containers and I was quite early on the Docker train, and for me, it definitely solves some real problems even at sma
by ripperdoc 6y ago
I'm running a couple of small servers with containers and I was quite early on the Docker train, and for me, it definitely solves some real problems even at small scale. Of course, as anything, it also brings new problems. Here's why I went for it:
- Before, when I just SSH:ed to servers and rscynced files, I had many situations where I forgot what change I did on a server, how it was set up, and so on. I found Docker when I was looking for tools to put those various commands and bash scripts into one place for central storage and easy re-creation of the environment. Dockerfiles and containers makes everything reproducible and reduced to the smallest amount of steps needed to get something correctly setup.
- I would find that something worked locally but not on remote due to different versions of some dependency. Docker images ensured I could test in almost identical environments. It's also easy to try new apps without worrying about polluting the current environment, so I'm not faster in trying out solutions and rolling back/forward dependencies.
- I would test things on the server, because I was not able to run the exact setup on my local computer. This takes time and risk breaking real stuff. Docker images fixes this.
- I would struggle with knowing what services ran or not. Part of this came from me not knowing all the ins and outs of Linux, so I felt it was hard to get an overview of what's running. docker ps makes it easy to see what's running.
- Updating a traditional app often required me to change more things than just update a source tree. It could be starting/stopping services, adding files in other places. So updates tended to become manual and error-prone (I didn't do them often enough to remember by heart what's needed). Docker and primarily docker-compose encapsulates all the stuff into simple commands.
- Before, my apps would use mixed sources of configuration - environment, config files in different places, command line arguments. More importantly, they would often be stateful, saving things to files that needed to be managed. With Docker, i was somewhat forced to align all config in one place and make everything else stateless and that makes things much cleaner.
- As a hobbyist, I rarely had the time before to go over the security of my servers. I find that Docker provides a better secure default in terms of making it clear what services are open to the world and by reducing the attack surface.
Of course, containers have brought some problems too:
- Lots of apps were not ready to be containerised, or required a lot of hacks to do so. So I've done a lot of debugging and sleuthing to find the right way to run and configure various apps in Docker. These days, the official Docker images are much better and exist for almost all apps, but there is still a lot of "messy magic" built into their Dockerfiles.
- More often than not you want to get into the container to run something, debug, ping, check a file, etc. This gets more convoluted than before, and you need to learn some new tricks to e.g. pipe in and out data. It's made harder by the fact that many images are so minimalistic you don't have access to the full range of tools inside the containers.
- Logging in Linux is IMO a mess since before, but still with Docker it's not great, just mashing up stdout for all containers and unclear rotation procedures. There are many ways to deal with it, but they often require lots more tooling, and it still gives me some headache.
- Yes, waiting for build and transfer of images adds a bit of time to deploy. And it's somewhat annoying to deal with two version control systems, e.g. git and Docker Hub. I haven't gone all in on CI yet but that would automate more and just let me use git.