
Dockerless, part 3: Moving development environment to containers with Podman - UberIsAnnoying
https://mkdev.me/en/posts/dockerless-part-3-moving-development-environment-to-containers-with-podman
======
algesten
At my company we did our own docker execution environment. We generally like
docker's layers and packaging, but dislike the runtime.

With AWS you already have a virtualization, why do we need another layer?

We packaged a super slim Linux with an init that just has some minimal code
reading out of AWS EC2 user info the conf. Downloads docker hub image and runs
it as a process.

No virtual networking or ssh access. No magic. Just a process on an aws ec2
instance.

~~~
brainflake
It sounds very inefficient to be honest. Containers don't add much overhead -
they are essentially processes that run in constrained environments (see
[http://man7.org/linux/man-
pages/man7/namespaces.7.html](http://man7.org/linux/man-
pages/man7/namespaces.7.html)).

Why dedicate an entire ec2 instance to a single container?

~~~
meddlepal
It wasn't that long ago that we were doing service-per-VM and really OP has
just described an implementation of that strategy with containers.

You would scale the virtual machines to try and reach optimal resource usage
rather than pick a standard fleet of virtual machines for all workloads and
let a scheduler do some kind of knapsack scheduling based on available
resources.

~~~
geezerjay
Comparatively, service-per-vm approaches are very wasteful and ineficcient,
moreso if a container orchestration system is used to manage the deployment.
It makes no sense to fine-tune VMs just to match the resource requirements of
a single process, particularly as they change over time and as that approach
leads you to a collection of custom-tayloted VMs that are needlessly
cumbersome to manage and scale.

Meanwhile containers enable you to run multiple services on the same VM, scale
them horizontally as you need on the same pre-determined amount of resources,
use blue/green deployments to spread your services throughout your VMs
automatically, and achieve all of this automatically and effortlessly.

------
reilly3000
I’m dense about alt-containers but why? Is this all about Docker security
issues? Is Docker too passé now that it’s in production everywhere? Why should
I spend money on not using Docker in 2019?

~~~
politelemon
> Why should I spend money on not using Docker in 2019?

You should use what works for you - ultimately you know your context and
circumstances better and you can make the decisions that affect you/your team
better than any of us.

HN is not an indicator of industry trends, but more of a set of interesting
articles and viewpoints that come together, though you will often see authors
and commenters pushing hard in certain directions.

In this instance, have a look at the author's part 1 under 'Reasons to
switch', see if any of the reasons given work for you.

[https://mkdev.me/en/posts/dockerless-part-1-which-tools-
to-r...](https://mkdev.me/en/posts/dockerless-part-1-which-tools-to-replace-
docker-with-and-why)

~~~
reilly3000
Thanks for sharing that, it provides a lot more context. I don’t run a lot of
containers, but the few I do I’ve naively run on an EC2 VM and ran into many
issues with the docker daemon. I’ve since embraced Fargate and haven’t looked
back. This takes me back to those hours spent troubleshooting (PSA: don’t use
snap to install docker if you want to have a good time) and see the appeal in
a daemonless container, and the root access definitely is a concern as well.

------
windexh8er
For a while I could understand divergent ecosystems for container
architectures. But all Redhat did was reinvent tooling, and not particularly
to any significant advantage. I feel like all these tools were the brainchild
of Dan Walsh as a rogue marketing campaign via Redhat to compete with Docker.
All these articles are the same... How to replace your exact Docker workflow
with Buildah! Now, less than ever, am I incented to use any products that come
from Bluehat.

~~~
altmind
I was never happy with the way docker was designed - it tried to steal too
much work from the operating system. Docker should never had logging framework
not should it be a daemon+client talking over socket, creating permission,
indirection and async problems.

Docker is straigh hostile to systemd, tried to bite part of its
responsibilities and does not cooperate with it in many parts.

If you want to run a docker image as a system service, its much easier to do
that with podman - the docker image will inherit the system.limits and will
behave like a Type=simple service with proper start/stop control and logging.

\-- add: worth noting, that podman and buildah are very alike "docker" and
"docker build" up to the point that you can do alias docker="podman" and can
expect all the docker features work. they consume the same docker files, they
build the same OCI images and can use the same registries. trying
podman/buildah/scopeo really got me thinking - where's the moby inc. business?
how can they commercialize a commodity?

~~~
cat199
> I was never happy with the way docker was designed - it tried to steal too
> much work from the operating system. Docker should never had logging
> framework not should it be a daemon+client talking over socket, creating
> permission, indirection and async problems.

> Docker is straigh hostile to systemd, tried to bite part of its
> responsibilities and does not cooperate with it in many parts.

you had me until the rationale for this was protecting systemd, which is doing
the exact same thing..

~~~
altmind
i had a specific operating system that already come with systemd. and all our
company's programs are packaged as systemd services. i dont like the way
systemd treated system.limits, udev, logind, dbus that is impossible to remove
and logging that is worse than rsyslog, but hell, we already paid the price
for adopting systemd, why paying extra for docker exibiting same behavior?

------
techntoke
If only Minikube could support installing rootless Kubernetes directly in
Podman containers on Linux. I love the concept of Podman, but without an easy
installer for Kubernetes it seems mostly pointless for most use cases.

~~~
cyphar
I'm pretty sure (though it's been a while since I worked on it) that the
usernetes project gives you all of the helpful scripts you need to get
rootless Kubernetes running. I don't think you really need MiniKube to support
it unless you have some specific requirement to use it.

~~~
techntoke
I still haven't found an easy and reliable way to do this. Do you have some
simple instructions, cause it looks way more complicated than it should be.

------
aleks_me2
Great article. FYI: OpenShift 4 uses podman as run command instead of docker.

