Some Reasons for Containerizing Applications

Containerization is a process of depolying an application to a machine that is exposed to users via the internet (using ssh). It is a highly recommended practice for running serives on a server. While it is not necessary to use Docker (tool to achieve containerization) on a server, as we can directly run the service on the base system - there are various advantages to do so.

Here are some reasons for performing containerization:

Isolation

Each service (e.g., Jellyfin, Minecraft Server, Home Assistant) runs in its own isolated container. This means they have their own set of dependencies and configurations, separate from each other and from the host system. This prevents dependency conflicts between services. If one service requires a specific version of a library that conflicts with another service, containers solve this. It also keeps your base system clean.

Portability

A Docker container bundles everything a service needs to run in a single package. This makes it easy to move a service from one machine to another (from an old server to a new one) with minimal setup configuration and installation. This simplifies migration and disaster recovery. You can recreate your entire server setup on new hardware much faster.

Reproducibility

Dockerfiles (the blueprints for Docker images) allow you to define exactly how your service is built and configured. This ensures that you can always recreate the exact same environment on every build run. This provides consistency across deployments and easy rollback if something goes wrong.

Simplified Management

Docker provides a unified interface for starting, stopping, restarting, and updating services. Tools like Docker Compose allow you to define multi-service applications in a single file, making management even easier. This streamlined administration means that you do not have to learn the specific commands for each individual service's daemon. It is almost like running a build script to have the service online.

Security

Containers offer a layer of security by default as the application and its dependencies are isolate from the base system. Even if a service within a container is compromised, the attacker is generally confined to that container and has limited access to the underlying host system. This reduces the attack surface of your server and limits the scale of the attack.

Easy Updates and Rollbacks

Updating a Dockerized service usually just involves pulling a new image and restarting the container. If an update breaks something, you can easily roll back to a previous working image. This achieves lesser downtime and lesser risk when performing updates.

Running Services Directly

Here are a few reasons you would deploy a service directly on the base system without any containerization:

• Simplicity for a simple service: If you're running just one or two very simple services that have minimal dependencies (e.g., just a basic web server serving static files), and you're comfortable with direct package management.
• Learning experience: For someone new to Linux, setting up a service directly can be a good way to understand how services are installed and configured at a deeper level.
• Resource constraints: In extremely low-resource environments (Raspberry Pi with limited RAM), the overhead of Docker might be a significant factor.

Conclusion

While running services directly on the base system is technically easier, the benefits of containerization with Docker (isolation, portability, and security) far outweigh the initial learning curve, especially for a home server that will likely run multiple services over time.