> "Dockerfile is simple", they promised. Now look at the CNCF landscape.
> with debs you need local apt repository
No, you don't need an apt repository. To install a deb file, you need to scp/curl the file and run `dpkg`.
>presumably you were building your deb with build pipeline as well
You don't need to rebuild the app package every time there is a new CVE in a dependency. Security updates for dependencies are applied automatically without any pipeline, you just enable `unattended-updates`, which is present out of the box.
> With debs you only have automatic-updates, which is not sufficient for deployments.
Again, you only need to run `dpkg` to update your app. preinst, postinst scripts and systemd unit configuration included in a deb package should handle everything.
> deb files have the same problems
No, they don't. deb files intended to run as a service have systemd configuration included and every major system now runs systemd.
> but here dockerfiles have an actual advantage: if you run supervisor _inside_ docker, then you can actually debug this locally on your machine!
Running a supervisor inside a container is an anti-pattern. It just masks errors from the orchestrator or external supervisor. Also usually messes with logs.
> No more "we use fancy systemd / ansible setups for prod, but on dev machines here are some junky shell scripts" - you can poke the things locally.
systemd/ansible are not fancy but basic beginner-level tools to manage small-scale infrastructure. That tendency to avoid appropriate but unfamiliar tools and retreat into more comfortable spaces reminds me of the old joke about a drunk guy searching for keys under a lamp post.
> What about deb files? I remember bad old pre-systemd days where each app had to do its own logs, as well as handle rotations - or log directly to third-party collection server.
Everything was out of the box - syslog daemon, syslog function in libc, preconfigured logrotate and logrotate configs included in packages.
There are special people who write their own logs bypassing syslog and they are still with us and they still write logs into files inside containers.
There are already enough rants about journald, so I'll skip that.
> but you no longer have to worry about your entire infra breaking, with no easy revert button, because your upstream released broken package.
Normally, updates are applied in staging/canary environments and tested. If upstream breaks a package - you pin the package to a working version, report the bug to the upstream or fix it locally and live happily ever after.
> ease of deployment
to
> running server farms in production is complex
You just confirmed my initial point:
> "Dockerfile is simple", they promised. Now look at the CNCF landscape.
> with debs you need local apt repository
No, you don't need an apt repository. To install a deb file, you need to scp/curl the file and run `dpkg`.
>presumably you were building your deb with build pipeline as well
You don't need to rebuild the app package every time there is a new CVE in a dependency. Security updates for dependencies are applied automatically without any pipeline, you just enable `unattended-updates`, which is present out of the box.
> With debs you only have automatic-updates, which is not sufficient for deployments.
Again, you only need to run `dpkg` to update your app. preinst, postinst scripts and systemd unit configuration included in a deb package should handle everything.
> deb files have the same problems
No, they don't. deb files intended to run as a service have systemd configuration included and every major system now runs systemd.
> but here dockerfiles have an actual advantage: if you run supervisor _inside_ docker, then you can actually debug this locally on your machine!
Running a supervisor inside a container is an anti-pattern. It just masks errors from the orchestrator or external supervisor. Also usually messes with logs.
> No more "we use fancy systemd / ansible setups for prod, but on dev machines here are some junky shell scripts" - you can poke the things locally.
systemd/ansible are not fancy but basic beginner-level tools to manage small-scale infrastructure. That tendency to avoid appropriate but unfamiliar tools and retreat into more comfortable spaces reminds me of the old joke about a drunk guy searching for keys under a lamp post.
> What about deb files? I remember bad old pre-systemd days where each app had to do its own logs, as well as handle rotations - or log directly to third-party collection server.
Everything was out of the box - syslog daemon, syslog function in libc, preconfigured logrotate and logrotate configs included in packages.
There are special people who write their own logs bypassing syslog and they are still with us and they still write logs into files inside containers.
There are already enough rants about journald, so I'll skip that.
> but you no longer have to worry about your entire infra breaking, with no easy revert button, because your upstream released broken package.
Normally, updates are applied in staging/canary environments and tested. If upstream breaks a package - you pin the package to a working version, report the bug to the upstream or fix it locally and live happily ever after.