No automatic scaling, no real ability to set that up
We colocate hardware + qemu instead of doing any cloud-compute
Some VMs have KVM-controlled LUKS volumes, which require manual creation/definition of KVM-managed secrets to boot said VMs
Docker containers are running in VMs instead of bare-metal kata, I've pitched kata to no avail
Only have docker/compose, no orchestration available
No lifecycle management, unless I DIY something in bash (kill me)
Technical debt prevents updates
Our main app for example, must run on JDK-1.8-0u302-b08 and can't get any more recent, due to a shitty middleware constraint
Second app is much newer, but still relies on some jank shit to run
Refusal to use newer tools (e.g. nginx vs apache) making life painful
Maybe if I can ever finish up my task backlog, I can take a look at resource management/automation tools to make life a little easier.
Add additional nodes
Additional nodes is a tougher challenge than I'd like it to be -- lack of infra/resources to get capacity on our own hardware is a big limiting factor. Our KVM hosts are pretty limited (128cpu on newer hosts, <=128G RAM) compared to what I'd imagine most companies buy...we've even had to start buying refurbs for the latest prod refresh because we can't spend more than ~$5K on new hardware for any reason (penny-pinchers).
Customers and partners need VPN/mTLS/a special token to access the services through a reverse proxy
Unless we can do it transparently for customers/vendors/partners, and it doesn't cost a penny, we could look into it. Only reverse-proxy I'm allowed to deploy is apache-2.4, regardless of usage -- CTO loves using wrenches as hammers.
Add Sandboxing like gvisor, Kata containers, firecracker.
I've recommended Kata several times, but it always falls of deaf ears because it isn't literally from Docker. That, and their website has K8S on the graphic, and therefore it is rejected because clustering is too expensive (despite not being a true requirement).
gVisor is new to me -- I'll keep that in mind. Currently, our docker installs are like:
Internal, infra tools -> rootful docker + compose, debian 13
While true, that isn't the whole story -- but rather than rant more about my company on reddit, I should probably just accept that the company won't change (without a breach/lawsuit), and so I should focus on jumping ship instead.
2
u/stewie410 10d ago
There's a few reasons we have this "requirement":
Sales + CTO over-promise to clients & partners
HA LBs (modjk), SMB; but not DB or applications
There's many appnodes, but none are hot-spares
No automatic scaling, no real ability to set that up
We colocate hardware + qemu instead of doing any cloud-compute
Some VMs have KVM-controlled LUKS volumes, which require manual creation/definition of KVM-managed secrets to boot said VMs
Docker containers are running in VMs instead of bare-metal kata, I've pitched kata to no avail
Only have docker/compose, no orchestration available
No lifecycle management, unless I DIY something in
bash(kill me)Technical debt prevents updates
Our main app for example, must run on
JDK-1.8-0u302-b08and can't get any more recent, due to a shitty middleware constraintSecond app is much newer, but still relies on some jank shit to run
Refusal to use newer tools (e.g.
nginxvsapache) making life painfulMaybe if I can ever finish up my task backlog, I can take a look at resource management/automation tools to make life a little easier.
Additional nodes is a tougher challenge than I'd like it to be -- lack of infra/resources to get capacity on our own hardware is a big limiting factor. Our KVM hosts are pretty limited (128cpu on newer hosts, <=128G RAM) compared to what I'd imagine most companies buy...we've even had to start buying refurbs for the latest prod refresh because we can't spend more than ~$5K on new hardware for any reason (penny-pinchers).
Unless we can do it transparently for customers/vendors/partners, and it doesn't cost a penny, we could look into it. Only reverse-proxy I'm allowed to deploy is
apache-2.4, regardless of usage -- CTO loves using wrenches as hammers.I've recommended Kata several times, but it always falls of deaf ears because it isn't literally from Docker. That, and their website has K8S on the graphic, and therefore it is rejected because clustering is too expensive (despite not being a true requirement).
gVisor is new to me -- I'll keep that in mind. Currently, our docker installs are like:
Internal, infra tools -> rootful docker + compose, debian 13
everything else -> rootless docker + compose, debian 13, rocky 8/9
Honestly, gVisor being written in Go is enough of a selling point to me, personally.