4 ms·
I worked in a small team that brought containers into a co-lo / bare metal / centos / rpm / puppet shop. There was extra shit for developers to learn but I don'
by raffraffraff 4y ago
I worked in a small team that brought containers into a co-lo / bare metal / centos / rpm / puppet shop. There was extra shit for developers to learn but I don't think it was waste. Not just because "everything is containers" nowadays, but because until they tried to build a container with their code actually working in it, most of them had little idea about how their shit worked. One example from the field: a VM got rebuilt and the app installed from scratch, but it wouldn't work. I hopped into the box and farted around with logs, strace, ldd, rpm commands and eventually realised that they introduced a dependence on a package that used to be installed on the system but was no longer there. It kept working on all existing machines but failed in a "build VM from scratch and run Puppet". Not only did that mistake make it out to production, but at that time few of the developers would have had a clue how to fix it. After the containerization of our services, this was absolutely not the case. (And honestly, we just conceptually replaced RPMs with containers, standardized all of our servers to the same build and forced developers to be aware of how their code actually worked).