[kwlug-disc] Topics I'd like to see...

[Mikalai Birukou]

>> I could probably do a presentation that demystifies that stuff at a high
>> level if people are interested in that.
>>
>> While I don't consider myself an expert in any of it, I've deployed 
>> K8S in
>> production (both public & private cloud) as well as deployed 
>> OpenShift, and
>> created terrible CI/CD workflows that have improved over time due to 
>> random
>> fiddling (i.e. the SRE stuff).
>
> I'm interested in the practical details.
>
> After doing some experiments with containers, they seem neat from a 
> packaging and deployment point of view. I'm sold that they can be 
> beneficial.
>
> But...
>
> But how is the lifecycle supposed to be managed? How are you supposed 
> to verify all your containers are up to date, and/or even verify the 
> up to date container has proper security patches installed?
>
> It seems like it's one step forward for packaging apps with weird or 
> intricate dependencies, but two steps backwards in terms of 
> infrastructure management.
>
> From people I've spoken to, the "solution" seems to be "only use 
> containers you made yourself", and "have your CI infrastructure 
> rebuild them every night to ensure they're up to date", which seems 
> like massively more work compared to running `dnf upgrade` 

With unattended upgrade scare, I hear, one should test upgrade before 
rollout. With containers we have stages: integrate, test, deploy. 
Upgrade feeds into integrate part, and test will follow because it was 
there. As a result, upgrades also go through tests.

Ya. That's the theory, that may be applicable to containerized system 
developed by you.

If someone else develops Docker Swarm based system, they should do 
integrate and test parts, giving you updated stack file that has 
references to new versions of containers. Of note, stack file also 
contains instructions about correct update approach of each service 
(e.g. db that touches disk and stateless things are different).