08:52:46 #startmeeting D105-Maxamillion-Containers 08:52:46 Meeting started Fri Feb 5 08:52:46 2016 UTC. The chair is decauseDevConf. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:52:46 Useful Commands: #action #agreed #halp #info #idea #link #topic. 08:52:46 The meeting name has been set to 'd105-maxamillion-containers' 08:52:52 #topic Containers 08:53:03 #topic Containers are not new 08:53:32 the original container, chroot 08:53:51 software running in an environemnt where it thinks root resolves to soemthing that isnt' 08:54:04 you allow it to exist in an alternative view, without modiying the software 08:54:15 it has a lot of aspects taht are not sophisticated 08:54:19 lack of copy-on-write 08:54:26 network isolation 08:54:44 the concept of execution runtime in this space 08:54:53 WHo is famliar with micorkernels 08:54:54 ? 08:55:13 the idea has existed for a long time 08:55:40 FreeBSD has been doing a pretty modern enablement for a while now 08:56:01 LXC is where things start to get interesting in my opinion 08:56:08 IBM introduced a set of tools 08:56:13 and poeple created vocabulary for it 08:56:29 it was a way of interacting with the system, and using system level componnents, that drive new tech today 08:56:36 namespaceing in cgropus in the kernel 08:56:44 definign runtime, adding constraints 08:56:52 systemd endspawn containers 08:58:06 in 2014, dotcloud released docker 08:58:14 in 2013, dotcloud released docker 08:58:34 in 2014, coreOS released Rkt 08:58:40 they came up with a spec for a container, and an image 08:58:54 that was the reference implmentation, and many discussions on standardizing on what that all means 08:59:04 2015 the Open Conatiner project launched 08:59:15 #link http://opencontainers.org 08:59:26 runc is a stand-alone commandline tool to lanuch containers based on this spec 08:59:30 it looks a lot like docker 08:59:43 and to my knowledge, is compatible with docker 08:59:47 #topic Docker 09:00:05 the reason I want to talk is that is pretty much ubiquitous 09:00:10 in Fedora 09:00:22 we're working on delivering some of these things for the sake of community involvement 09:00:26 and delivering new tech 09:00:35 docker daemon has language bindings for diff languages 09:00:40 i'm most fmailair with python 09:00:45 a container is an instance 09:00:50 basically a tarball with metadata 09:01:01 the images are build with a docker file 09:01:13 and I like to reference SELIinux stuff 09:01:24 Dan Walsh pushed SELinux upstream into docker 09:01:33 "containers don't contain" to steal his quote 09:01:51 there are many exmaples of containers redefining application context, it doesn't constrain it 09:02:03 we needed to lower surface for exploitation 09:02:08 #topic Docker File 09:02:14 effectively, you have a base image 09:02:25 you want a maintainer ref, so you can get feedback 09:02:32 each "stanza" is a new layer 09:02:36 and you can share these layers 09:02:45 build time will cache that layer, to be re-used 09:02:54 we can expose ports, ad files directly into the image 09:03:02 so that when the container is launched, it has it in there 09:03:23 one thing this enables, and something that is popular 09:03:33 in a traditional system environment 09:03:40 (considering VM's are traditional now) 09:04:06 you can migrate an application, let's pretend it is written in language X (to avoid religious debate) 09:04:19 and it may not be compatible with the latest version of Fedora 09:04:33 we can take a platform of a F22 based image, and then run that on Fedora23 09:04:45 this enables us to take application runtimes, away from being bound to the host 09:05:03 this allows us to not have to duplicate the Operating system, the filesytem, etc... 09:05:19 containers don't replace virt necessarily, but, you have a new ability to do this now. 09:05:28 #toic Microservices 09:05:37 not sure which is the chicken/egg 09:05:47 containers are the most popular way to deliver them 09:05:55 I like to reference back tot he microkernel ideas 09:06:05 (which are old ideas) 09:06:18 you have small compnonents talking to eachother via IPC, and even across the network 09:06:29 we could geo-disperse, and load balance, and spin them up and down 09:06:34 microkernels can do that 09:06:40 the Amoeba operating systems did this 09:06:50 they ahve the low-level system running anywhwer on the net 09:06:57 take that "up the stack" 09:07:06 for applications, we have siliar parallels 09:07:17 we have tiny components that can get moved around 09:07:23 sysadmins know this via pipes 09:07:42 you can daisey chain your 30-command-one-liners 09:07:52 but that is not the best way to run enterprise 09:08:02 Services are the "unix way" airquotes 09:08:08 "do one thing, do it well" 09:08:23 decoupling tightly coupled compneonents 09:08:36 if they are loosely coupled, you can disperse system compnonents 09:08:42 and then can interact, as if they were local 09:08:55 you can do a loopback network to host it in one environment 09:09:08 now you ahve infra clouds, multizone, multi-tenant environemtns 09:09:17 that will hopefully add resiliance to the service 09:09:33 you can then have smaller compoennets, easy independent tests, and iterate faster, adn get code quality up 09:09:44 we don't sacrifice quality, and get faster development 09:09:51 #topic Immutable INfrastructure 09:09:57 this is a new-ish one 09:10:06 it is effecively fully-automated 09:10:12 minimal human interaction 09:10:24 that isn't just about firing up virt templates, with post-boot task runs, and configmanagement 09:10:32 the goal is being done at deploy time 09:10:35 you don't change it 09:10:52 "dont' configmanagement in the enviroment, do it at build-time." 09:11:02 have these pieces taht can be tested as a cohesive unit 09:11:09 to verify that the thing in testing is in prod 09:11:19 there is a assurance that nothign has changed 09:11:43 unexpected changes, human or cfgmgmt, are easily detected, and avoided 09:11:55 we deploy these artifacts 09:11:59 it can be a container image 09:12:10 a docker file, that runs and does it's thing, youc an distirbute it and run a service 09:12:18 there should be no added requirement for cfgmgmt 09:12:23 you don't need to run it on the end-host 09:12:27 the container image build 09:12:38 the delivery mecahnism is different 09:12:47 yo uhav ea tarball, with everthing you wanted 09:13:00 artifacts can be tested and graduated 09:13:07 it can load diff environments 09:13:12 the image can go through unchanged 09:13:20 some update of library Zed 09:13:29 you have version 1.1 in deve/test/stage 09:13:38 1.2 has an updated security fix 09:13:42 ops deploys it 09:13:49 something breaks 09:13:57 what is your rollback strategy? 09:14:02 wihtout containers, it is much ahrder 09:14:12 #topic Deployment Models 09:14:26 Let's say oyu're running v1 09:14:28 you wanna update 09:14:34 you have your tests/CI 09:14:37 and you update to 1.2 09:14:40 it tests fine 09:14:46 you roll-out to env 09:14:54 what happens when something breaks on one node? 09:15:04 you can think of a horrible doomsday scenario 09:15:08 power loss 09:15:13 custom rpm triggers 09:15:20 commits to master from a new person 09:15:27 how do you verify compnoents? 09:15:35 how do you know what state your filesystem or kernel 09:15:48 if you lost power 09:15:58 how do you log-into your system 09:16:03 what if we could avoid that 09:16:15 rpm package triggers 09:16:18 ? 09:16:20 here is the docs 09:16:30 #topic RPM Package Manager 09:16:39 each package manager has an order of operatoins 09:16:47 at each step, a side-effect can happen 09:16:54 in an upgrade, this is mutable state 09:17:03 something can happen mid state 09:17:17 #topic Immutable Operating Systems 09:17:22 this is where project atomic comes in 09:17:42 the idea you can have these deployment artifiacts that can be "all or nothing" deployed 09:17:46 it includes newer tech 09:17:52 and it is built on top of traditional tech 09:17:57 we're iterating ont he world of before 09:18:05 it is an upstream project 09:18:16 CentOS and Fedora are working together 09:18:30 being a Fedora person, I"ll talk about our involment, but CentOS is working here as well :) 09:18:45 #topic Fedora Atomic Host 09:18:55 what is changing is the delievery mechanism 09:19:02 there will be some pain in getting folks up to speed 09:19:08 but in a immutable env 09:19:14 you don't want to do package installs on a live system 09:19:26 it is a minimzed footprint 09:19:38 we want it to be the best at running containers 09:19:46 it is easy to do, thanks to OSTrees 09:19:55 that is our new deployment artifact 09:20:03 orchestartion is where kubernetes comes in later 09:20:26 rpm ostree is a root filesystem tree, simliar to git commits 09:20:30 you can revert back and roll forward 09:20:33 it has ref ids 09:20:42 RPM ostrees allow us to build trees from sets of RPMS 09:20:55 you can use software like you have, but then use OSTree to be the build artifact 09:21:19 there is not "we don't know if dracut finished running initramfs" 09:21:30 entire trees can be tested as a single unit 09:22:09 you can go in and inspect atomic hosts to find version strings 09:22:14 #topic Orchestration 09:22:21 you have containers 09:22:26 how do you run across many hosts? 09:22:29 Kubernetes 09:22:34 the few main vocab 09:22:39 pod, service, replication controller 09:22:57 pod - set of containers. scheudles as a unit. They ahve IPC, Net, and they can speak to eachother as if localhost 09:23:08 Service - one or more pods, takes them as a unit 09:23:17 rep controller - manages those services 09:23:26 pluggable options for persistant storage options 09:23:31 #topic Developers 09:23:46 my hope was that developers can apply these to their workflow 09:23:51 OPenShiftOrigins provides this 09:24:11 it is a self-service, for devs to submit code to, in a configurable pipeline 09:24:37 you can then, take that, and run it using openshift, or you can take container out of that environment, and run it directly in a kubernetes env running on atomic 09:25:00 this means you can hav e afully immutable pipeline from dev to production 09:25:04 #topic Q&A 09:25:20 Q: Is a pod always on a single-host in Kubernetes? 09:25:36 A: Yes. To my knowlege, yes. as defined recently-ish 09:26:11 Q: you're including configmagmt in the immutable infra. It seems to me, for things like keys... do you hve a sense of how many poeple are doing this? 09:26:27 Q: Do oyu have much perspecitve on how many people doing cfgmgmt at build? 09:27:04 A: I offer it as a stepping stone. Everything you used to do, you can do at build time now. You can suuply config data to containers. I konw of about half-a-dozen folks who inject in build-time. 09:27:24 Q: The other thing folks use config management for is to build the kubernetes files to begin with. 09:27:46 A: yes. esp if you have much investment into a cfgmgmt solution 09:28:32 Q: Based on the turnout for cfgmgmtcamp, bigger than last year, the consensus was not that cfgmgmt is dead, it just needs to evolve. 09:28:39 #topic Thank you all for your time 09:28:41 #endmeeting