Docker changed what I consider worth setting up.
Without containers, trying new software usually means committing to an environment: Pick an OS. Install dependencies. Open ports. Configure access. Hope you remember what you did the next time you come back.
Even when the goal is just to try something, the setup feels heavier than the thing you’re actually interested in.
The cost in time adds up, now you’re more hesitant to fire up the service or tool.
Running software instead of installing it
Containers let me run real software without committing to the machine it runs on.
Instead of installing something onto a server and managing that server over time, I run a container that already knows how to be the software. When I’m done, I stop or discard it. If it’s broken, I just simply remove it, and if I need it again, I just run it again.
…and that’s why I love containers.
Jenkins as a concrete example
In a non containerized setup, running Jenkins means creating a machine, installing Java, installing Jenkins, opening ports, logging in, and then deciding what to do with that machine afterward. At this point, I’m already managing a whole box before I’ve even touched Jenkins.
With Docker, this is usually all I need:
docker run -p 8080:8080 jenkins/jenkins
If I want it usable without tying up my terminal (or, as my boss would say, hijacking it):
docker run -d -p 8080:8080 jenkins/jenkins
That’s it! Jenkins is running! No OS decisions or package installs needed.
The setup alone was getting in the way of the real fun.
Disposing isn’t a big deal
Once containers become cheap to create, they also become cheaper to delete.
To see what’s running:
docker ps
Stopping something I’m done with:
docker stop <container ID>
Removing it:
docker rm <container ID>
The environments stop feeling precious. When I am done with a container, I stop and discard it.
Where this leaves me
Containers made me more willing to try things.
It just feels easier to start.