Ask HN: Has anyone migrated off containerized infrastructure?
I did, somewhat.<p>Running between 8 and 14 Linode and Digital ocean VMS, I wanted to research if K8s or any docker setup would be good for me.<p>I have been doing linux server maintanance for over 16 years now, set-up and grew three webhosting companies. My current VMs are for my own tooling (selfhosted mail, nextcloud, matomo) my startup (mostly servers crunching OSM databases) and some leftover client hosting (mostly Rails and Sinatra).<p>The issues I ran into with Docker and k8s were all small and could probably be overcome given extra time and effort. But combined, <i></i>I decided that containerization does not solve enough problems for me, that it warrants all the new problems it introduces<i></i>.<p>In no particular order:<p>* Firewalling: On a normal linux machine or in a cluster a long-solved problem (resp: iptables&#x2F;ufw or dedicated firewall servers&#x2F;hardware). With containerized: no idea. Seems a largely unsolved issue, probably because &quot;containerization should not do any firewalling&quot;. And partly because of how network mapping works, the problem is mitigated (but not solved!) there.<p>* Monitoring: at least three popular docker images that I used forgot to add logrotation, crashing after long term running. That in itself is bad (and shows lack of detailed finish in many images) but it shows you need to monitor. I used munin and am now migrating towards prometheus&#x2F;grafana, but I really have no idea how to properly monitor a flock of containers. Another problem that has been solved for ages, but requires time&amp;effort in a containerized env.<p>* Timed jobs (cronjobs). There is tooling to spin-up-and-run containers on timed schedules, but no-one as easy and stable as having Ansible write a file to &#x2F;etc&#x2F;cron.d&#x2F;osm_poi_extract (or use systemd, fine with me).<p>* fail2ban, tripwire, etc: small tooling that is hard to do or requires extra attention in a containerized setup.<p>* unity: if you rely on 3rd party containers you&#x27;ll quickly have a rainbow-spectrum of machines: Ubuntu LTS, Ubuntu edge, Ubuntu ancient, Alpine, CentOS, a rare freeBSD. The interface is consistent, the underlying tech is not: troubleshooting is a terror if you first have to spend 20 minutes of googling &quot;how do I know what version Alpine I have and how do I get curl on this damned thing to see if elasticsearch is maybe giving results on localhost&quot;.<p>I realize that my 16+ years of prior linux-sysadmin experience hinder me here: I&#x27;m probably trying to make a containerized setup do the same that I&#x27;m used to, but which is not really needed (tripwire, fail2ban, firewalls?).<p>But for me, containers -in production- solve no problem. Yet they introduce a whole range of problems that in a more classic setup have been solved for, sometimes literally, decades. &quot;Infra and state in a documented revision control&quot; is solved mostly with ansible, saltstack, chef or puppet; this can and should certainly evolve and improve. Networking is solved with, well, networking. Hell, one of my previous hosting setups had a cron job that would get &quot;the latest &#x2F;etc&#x2F;hosts&quot; hourly: that was our entire DNS setup. it worked. reliably&quot;, &#x2F;etc&#x2F;hosts and docker, don&#x27;t get me started (the reply would probably be: but you don&#x27;t need &#x2F;etc&#x2F;hosts in k8s).