Building Container Images with OpenEmbedded and the Yocto Project - Scott Murray

so I'm Scott Murray and this presentation is building container images with openembedded and the octo project a little bit but myself I've been using Linux since 1996 first few years I did some hobbyist stuff for my own amusement and then in 2000 I started actually working on Linux for a living doing embedded and non-embedded desktop software stuff the last few years I've been working for a consulting group currently a principal software engineer for them vocal groups a services company we specialize in embedded Linux and open source software and kind of run the gamut of hardware software design build development and we do training and were a Linux Foundation training partner if you have any interest in that you know come up to one of us and ask about it so it's a San Jose company but we're quite distributed I live in Toronto Canada and we have people in Europe and all over the US so quick agenda of what I'm gonna try and cover so a really hopefully quick overview of openembedded and the octo project I'm hoping that everyone has got a reasonable familiarity with those a little you know sort of spiel about containers probably also something that most people here have some knowledge of already and then I'm gonna talk about what openembedded can bring to the container sort of situation and then I'm gonna walk through some example build configurations that I've been tinkering with to try and build both full distributions and application sort of micro service type containers and then a little bit about nesting images to try and build a like factory install sort of pre installing application sandbox in an image during the build process which is surprisingly not not an easy thing necessarily um if you kick caveats I am NOT a container expert by any stretch of the imagination when I submitted this talk I thought it would be a good IDE good opportunity to learn some so I have been doing a lot of a lot of googling and learning things but this presentation I do not really go into the details of how you would take the images that are being generated and actually using them in with docker or Runcie or any of the other tools as well container technology every month there's some significant change I might have missed something you know the way of tooling that if you know what's something quite useful either come up to me afterwards or during that I'm gonna you know take questions at the end hopefully you know throw something up and I am assuming a bit of openembedded and you know Yocto project and you know maybe a little bit you know docker knowledge because I'm not gonna go deep dive in some things so our hopefully quick summary of openembedded in the octave project openembedded is a build system and the metadata to build embedded Linux distributions it is not itself a Linux distribution the octa project is a collaboration project this has been running for eight years to aid in the creation of Linux products based on you know open embedded as the technology behind it and Yocto project provides a reference distribution called pocky which is built with open embedded and provided by the octave project and then so that's the goal is to have that Pocky acts as a starting point I prefer to Pocky and some of the configurations but I'm trying to do things in my example configurations that would also work if you just use plain open embed it yourself and don't use Yocto project Pocky some quick feature list here so one of the big strong points of openembedded is has very broad sweep your architecture support basically because vendors support it with BSP layers that they actually maintain themselves and contribute so the layers are basically a way of customizing your configuration so it's basically has stacking metadata and that's one of the key strengths of open embedded and your project because it's an embedded you know Linux distribution sort of tool that's sort of the focus on with it I have worked on projects where we have built server-side stuff with it but the goal is usually in an embedded system to build small images so that is kind of one of the focuses of openembedded it's notable for a regularly scheduled basically every six months there's a release pretty much it's one of its strong points it's integrated license and source publishing compliance tools which make it quite easy to publish your license you know information for an embedded system and actually you know archive your source to provide to somebody who asked for it one of the sort of current projects it's ongoing for the last couple releases is full binary reproducibility which Debian has also been working on which is a you know boosts your confidence level in your images that you can reproduce the contents and it's also there's some security benefits there as well so containers no surprise hopefully to anyone are basically operating system-level virtualization as opposed to virtual machines that basically virtualize a whole machine Linux implementations you know have been around for a while I mean basically this is like you know going from Schrute to something much more substantial nowadays it's namespaces and cgroups the linux control groups feature so I mean it's sort of the old-school tool these days is Linux containers lxc but then docker and run see and even systemd has system VN spawn which allows you to actually even with a stock Linux system with system be installed run they you know system of containers if you put your mind to it to muddy things a bit nowadays was actually his work on it what the you know they refer to as lightweight VM technology so clear and cata containers actually do virtualization at the Machine level but its aims to be so lightweight that it doesn't have the performance impact and startup that typically VMs do and that's because that's one of the key strengths that people have for containers is quick startup and ease of starting and lightweight resource usage so these are new technologies trying the benefits of vm's in the same space fortunate is all I'm going to talk about in that about Cadogan Tanner's there isn't really a integration in upstream openembedded there are some layers floating around but when I was looking at that looking at it they're a bit stale so there's probably some work to be done their container images are you know run the gamut you can do a full Linux distribution install in there or nowadays it's more typical to have small images with potentially a single application in just its dependencies that's pretty common out on this microservices model and you know having kubernetes orchestrate a big system so continuing that vein the common use cases are sort of the more old-school thing is trying to run an application that has you know gone stale it doesn't actually you know what a new new system doesn't have libraries that will work for that application you can sort of run it inside a sandbox sort of the you know container and actually run it with its own set of libraries and actually get that it will run on a new system one of the easiest for that is builds you want to keep your potentially builds running on newer machines you know things shift over time in a tool chain or in Litzy you can get stuck with you know your bill doesn't work anymore on a new system that's one of the use cases sandboxing an application to isolate it so this is more of the security sort of idea where you basically can't see the whole file system or all the other processes there's you know debates on how good you know container security is versus virtualization I mean it's improving all the time but I mean nowadays or I mean it's a heavily researched area you know the black cats are always trying to work out how to get out of a container environment break out of a namespace but it has come a long ways in the last few years and so the other use case I started already mention is micro services with this like starting on demand for orchestration and you know potentially migrating services from one machine to another so typical container construction these days is you start with a minimal system a debian or Ubuntu or very commonly now alpine Linux which is quite small and then you add your required packages that you need to run your software or your particular application and then you might actually compile some things actually install a tool chain build a particular piece of software using its build process and then you actually prune down you might remove actually the tool chain that was in there and everything other you know the source for that application you might have compiled to try and make a very small image and that's desirable because it reduces the attack surface less software is better and if they in the container makes it easier to maintain again from having with software in migration time and systems where you're actually shifting containers from hosts the hosts in like a you know clouds scenario smaller is you know easier to transfer less time so what are the potential drawbacks of you know some of these types of things these sort of common you know scenarios of how people build containers reproducibility is not necessarily great in docker you sort of rely on people keeping the labels sort of saying and not over writing an image and keeping the same label and being good about actually versioning things that might not be obvious if you're actually running a docker file you might pull down something different than the last time you ran it and unless you're careful to pay attention that would be a surprise and that comes into like the base debian and Alpine images might upgrade you need to keep track of what's going on and then you see things in docker files you know I'm not a doctor expert but looking around people do things where they do an automated apt-get update and upgrade because they want the latest bits which is good I mean security wise that's the smart but unless you're actually careful to track what's happening when every time you run the docker file to make a container it might be quite different each time right I mean you have to go look at the package man you know a manager and see what's in there and as well there's things where you see people talking about what you can pin a package version and you know in apt or apk but I have seen reports of things where people go to reproduce a container and Alpine basically don't archive necessarily all the old versions of packages and so you go to reproduce and it's gone and you can no longer build that without doing a very intense web search to find an old version of the the package and that's not ideal really I mean if you if you want to actually be able to tell people this we know what bits are in these images and we can reproduce it that's not good as well I mean so that as I sort of been reiterating you actually have to put some effort in and this C scheme with like you know using doc files or other mechanisms to compose images and so something is a trust issue that the upstream is not going to change on you this comes in as transparency and sort of a security aspect of it you do have to trust the builders of the base container images and so if you're you know paranoid or your lawyers are paranoid you want to really be sure that you know the origin of the bits that are in the image and so I mean distributions any on you you this you can build up a you know confidence level you know trust Debian that the developers actually aren't going to sneak something in but then there's the you have to be sort of sure that none of the Debian package maintainers are gonna sneak something in and get it by people so it's you're kind of at the whim of maybe distribution update policies on the security front and having it you know if you're pulling in a large amount of software and a container for something large like node or you know Python sort of software framework it's definitely a challenge potentially and of course it's also anyone who's done much container work it's very common refrain of well containers if you you know open SSL has an issue have to update every container image to pick up the you know CVE fix so I mean that's something that all address about I mean you can just do your app get updating rerun your docker files or whatever and build new images but it's not necessarily ideal the other thing is license compliance potentially we're not talking to a lot of software I mean Alpine is is quite minimal being a base image it's only several packages but I mean if you do have a legal team who wants to be able to produce a list of the software the line licenses be able to produce a source archive of everything that's in an image that's not straightforward necessarily without being quite familiar with the package manager and being able to script up pulling it out of you know apt or fetching all the source packages and you know scripting up a mechanism to build that so that's not ideal customization is where things really get more sort of wonky for if you're you know it's one thing to have a docker file it does you know W get such-and-such dark Targa G's ed configure you know make bla bla bla bla but if there's a package that's in the distribution any for some reason you want to change its configuration and need to rebuild it ideally you would do with something that's compatible with the package manager and that kind of gets into the state where you might actually need to know more about building packages with the distributions build process you know using its package build things like open build server is that a bit but then it gets into things where if you were trying to do containers with a distribution for some reason on an architecture that the distribution didn't support bootstrapping something like Debian or Alpine is a pretty big job if you've got done it before and so that's not something that average person is going to do and so in an embedded system say you wanted to do sandboxing and you want to use a very small distribution and you want to use Alpine and you're on a MIT system you're gonna be in arm you can't do that basically you're kind of stuck unless you really like build systems so he's open embedded in the octa project a solution to these types of problems I'll sort of run through the same list reproducibly wise we have a good story basically you can rerun the build using the same set of metadata and should get the same results that's improving all the time as I sort of looted - at the beginning ideally within a couple releases it should be the case that with the right configuration you should get the same binary is every time several distributions are working on that but you will actually be able to pretty much do that yourself transparency wise because the everything's bootstraps and scratch you have all the source in hand if you want a lot of things you have it it's pretty straightforward the security front there's eighteen months of support per openembedded release doctor project depending on there's a fine line of who's actually doing the keyway there but it's sort of been discussed about long-term support releases for for open embed it but this hasn't really taken off yet so on the other side you have Deb eNOS pretty much five years when I can tell Alpine is a two-year promise with some potential exceptions for certain packages they might actually do updates for so that's not actually the opening bet is look too bad and that sort of like license compliance that's pretty much all built in basically by default you're getting your license manifests you can do license text archiving even inside the image if you want to have it contained with the container source I carving is a pretty straightforward thing to do so we're that's probably one of the stronger arguments for using openembedded for containers on the customization front because it's a you know pretty much the purpose of openembedded is to be very flexible the layered metadata in the build process you can almost customize anything but it comes into your skill level I mean simple config option tweaks are pretty straightforward but if you get into wanting to change tool chain security flags and stuff that becomes more involved you'll have to be somewhat expert you know in tool chain stuff to do that as well pretty much any architecture that a BSP layer exists can actually be targeted that's useful for embedded if we want to do sandboxing with container tools we can do it on platforms that don't actually have mainstream Linux distributions that are geared towards containers we can build our own so then we get into some more general issues package availability of you know what's what's the story there so Deb you you boot you it's really hard to come up with a a good sort of solid number but it's tens of thousands of packages even for arm it's these days it's tens of thousands of packages alpine from what I can tell they pretty much build five thousand packages with their system they have a custom system so that but it is in the same ballpark but not as dramatic as Deb uni openembedded at the moment is about 2300 packages by going rep my recipe count some of those are going to be toolchain ones so it's not necessarily a really solid number there but that's in the open them at a core and met open embedded layers which are pretty much heavily the heavily Qaid layers so those recipes are likely to be usable right off but there are many more recipes if you actually start searching around but then your confidence level of reproducibility and how well the light or the recipe for that software it's gonna work will be not as good one thing to note is open in minutes node and Python module support is is this quite a few like the commonly used packages that there are recipes for but given you know the sort of rapid development and the sort of wide array of new modules popping up that people want to use in their stacks that's probably a bit of a problem you might actually have to write recipes for some of those yourself in order to use them which would be good if you could then upstream them to a project and the cycle would sort of continue but then on the ECU's fronts one of the things that you know you get with debian or you boot to or alpine is the like apt-get or apk install sort of experience where you're pulling from a package feed you can do that with openembedded it's a bit more work to configure them probably the average person is really going to be comfortable with necessarily write off it's not the most well-documented part the project in my opinion but is doable there are enough wrinkles that it's probably not something everybody would do and so that kind of means that it's maybe more the case that's small relatively fixed content images are going to be the thing that will be more straightforward to handle with open embedded resources it's a new thing to learn if you haven't used it before and you want to jump in and start building container images you're gonna be a you know there's a little learning curve it's a build process so there's actually quite significant hyper resources if you're building you know much software and a lot your maintenance may involve actually dedicating someone to keep track of the project and you know sort of focusing on it so that said so there are pluses and minuses I'm not saying it's just gonna change your life and this is the way that everybody should build containers that's not a slam dunk so on the to get to the sort of mechanics of what we would do with open embedded so back in the pyro release last year I believe we're call crackly or late 2016 there was a container image type added and so on the appear in your configuration you can just set the image file system type to container and it basically produces a tarball with there's no kernel it actually disables post install scripts because you're not gonna have a normal init process there won't be run and then you have to set the kernel to be the dummy kernel which basically won't build anything and that's it you actually will get a tarball with just what's configured in the image so that's how we would build a container if you actually want the tools to do something with that container like on target basically there's a meta virtualization layer it provides the sort of gamut of you know Linux containers run C docker which is not a quite the latest version but it's in the current master branch is close as well it's got the open container image tools and this configuration frame fragments for the Linux dr. kernel that when you pull in the matter virtualization layer will add the required kernel configuration to actually run container tools one thing to note is there's currently no support for building you like a OCI or you know a docker image during the build which would be mean like running a docker file or doing docker compose type of stuff because docker basically has a daemon that it has to have running in order to do most of these types of operations and that's kind of a difficult thing to achieve with the build process I'm poking around there there are so many web pages where people talk about alternate ways to actually use different tools to try and actually build a container without using docker itself if you actually want a dock or compatible container because it has its own format I haven't actually figured it out yet if anyone has any ideas maybe come talk to me or throw it up at during the question period as well token labs they have a booth down in the vendor showcase they have a oryx Linux distribution that they support and it's basically based on open embedded and they offer a commercial support package for it and they actually have container support as part of their system Horrocks and they use run run sieve from the open container folks as the sort of container running system on the target and there's the URL there I haven't played with it yet might poke around at some point just to kind of see how they do some things but it looks pretty much like they use meta virtualization and grab the tools but that you go talk to them at their booth if you want some details I think all right so I sort of rushed through the pros and cons why we might want to use openembedded and you know Yocto project floor building container images I'm gonna try and get through my examples before I dress run at a time so I have a few things in mind when I sort of submitted the talk one is it'd be nice to have a container image that I could actually run an open embedded build in its I mean I you know most people carry around like a Debian image or something to kind of give them max and compatibility for doing builds but it's been a thing for a while that open embed it has a thing called to build appliance virtual machine image which is inside the openembedded distribution you can build it so it can self host its own build and I was like well I'd like a container to do that and not have to worry about building a VM image and stuff so that's one of the things I've tried to accomplish another one was to see well how close can I get to something that's like alpine Linux size-wise you know how hard is just sort of get sort of similar functionality and so can some configuration options to do that and then there's this building a single application container so the typical microservices type of thing and then my sort of ideas around building an image that's preloaded with application containers and this would be potentially useful for factory image builds if you're doing sandboxing of applications on your targets all right so this is my example for a build container and so for most of these I walk through how you would just sort of ad hoc do it by putting things in local comp which is the main configuration file for open embedded if you've used it at all you've probably tweaks things in open in local kampf so here I'm actually just setting the machine to the x86 64 qmu compatible machine I'm setting the FS type to container which I've mentioned gives us a sort of bare-bones image I'm actually setting the kernel to dummy because that's required by the container image type and so one of the things is I actually have to set the locale to be included so I'm setting a language here but has nowadays openembedded the bitbake tool uses Python 3 and it needs a locale in the image to actually work so I have to actually tell it I want one because I'm gonna build a core image minimal image which normally wouldn't have any locales in it and then this is the magic these two package groups are defined in a week or in the build appliance stuff there's actually a package group self-hosted recipe that these are two package groups out of four or five but these two are enough to actually build an image on top of core image minimal these two package groups give you all the tools to actually do a bootstrap build and so when you build this it's about 150 megabytes for emu x86 64 the build process is interesting because the the self-hosted package group that the build appliance Inc is got a graphical desktop and extremely minimal one but you when you do a bit baked that package group gets built all of it and so your bit you it's interesting because web engine there I think it's built which takes a lot longer than you'd expect building something like this should take but then it doesn't actually end up in the image so that means if you were trying to build a minimal image or you want to reproduce as quickly you might tweak some things to try and speed that up and maybe prune out a few things so because the container type image type turns off posts and stall scripts things like the volatile directories functionality that's on by default and openembedded won't break is maybe too strong a word it doesn't do necessarily what you expect because without those init scripts running there's a few directories miss it and some software works perfectly fine but the bill does not so to work around that we need to sort of populate a few things and it's a very volatile temp is one of the sort of big ones so we could actually script up a little bit where we take this container image like we get and actually run the NIT script that ends up in it to create those handful of directories we could tweak it as well in our like make an image recipe and and basically create them by hand as well that's sort of a couple different options there the base files package is what controls the creation of these volatile directories we could BP append that and actually tweak the recipe to change the behavior as well your user for doing your builds needs to be created the build appliance VM image actually adds a special it has a recipe that adds a builder user we kind of want to work around that necessarily you might actually want to have your own local user so that gets into more like docker configuration or system D and spawn tweaking with then spawn config and as well your build tree to actually get at it you need to do docker volumes or do some buying mounts but it works perfectly fine I was doing test builds works fine and this is something I actually probably tinker with some more because I would like to actually have support for this an upstream openembedded it actually seems quite useful so to follow up this is actually a an image definition of sort of some of these ideas without actually having to do it in local comp you could make a layer put this image definition in it and it's just on top of open like it was just so a core pretty much and if you bitbake build container you will actually get an image that actually pretty much works and you then you can actually run bitbake inside that container one of the things to note i have thrown in adding the x4 type that's sort of a convenience thing for system VN spawn you can just stick an X for image into the barrel of machines directory and this ends the run systemd container or and spawn tour started so and this is my sort of hacked for fixing the temp directories using the route route efest post process command hooks it's not pretty but it does work so one of the things is they start poking around is using @qe x86 64 it would be nice if I didn't actually have to set preferred provider virtual kernel to use the dummy kernel and there's a one extra little package that team.you x86 64 pulls in that is not useful in a container so this is like a machine definition you could throw somewhere as they know like you know make a a small little BSP to use for containers that would basically turn off I think it's V 86'd is the package and force the use of Linux dummy without having to add it to let local comp all the time okay so that's pretty straightforward that didn't seem that bad actually it was took a little bit of you know wrapping my head around what the self hosting package groups we're gonna be needed and things like that and there's some tweaking but it's not that bad it doesn't take much configuration do that so let's try and raise the bar let's try do you like Alpine ish type of image so one things about Alpine is it uses the muscle sea library instead of G Lipsy that's probably the biggest size reduction that that they get is doing that I've you know the previous talk but probably I assume that was discussed I've spoken it back in the spring also but size reduction muscle is the biggest bang for your buck in reducing sizes of openembedded images so this pretty much gets you not that far off actually you can bitbake core image minimal with this container sort of configuration and just switching the muscle produces something that is not that big this is the image manifest and so there's a few odds and ends in here that you wouldn't think you'd need this doesn't use my machine definition so it has me 86'd in it but it has a few other odds and ends that actually has assists v in it hooks it has the update all Turner's for the AU package package manager I'll talk a little bit about you can't prune these things out actually because you're not gonna actually have an it scripts run nor in one of these containers you might because by default alpine supports that you could do that you could actually run in it inside this container and actually start up multiple things but most people don't actually do that you can still go ahead and prune those it so as I mention on this slide so this actually is about four point eight megabytes but there's no package management and so alpine uses its own at package manager apk and so if I actually configure with a package as the package manager in the image we do end up at eight-and-a-half mix which is in the ballpark of double the size of an Alpine image unfortunately one of the other features is Alpine is it signs all its packages that's configurable we can actually do that with au package and openembedded we can also do with our PM but when you turn on RPM as the package manager you get an image it's about a hundred megabytes so that's pretty much a non-starter i assume for anyone who wants to do micro services that's quite a bit larger than you could do with pretty much everything else and like i said further pruning is possible one way is with a custom district configuration and as well all the like update alternatives and things like that there is an option that's not really obvious called force ro remove which is force read-only remove because when you build a read-only image and openembedded i mean it's pretty obvious you're not gonna actually update the alternatives links when you install packages because you're not going to install packages and so when you build an image that's read-only all this stuff gets pulled out but a couple releases ago a knob was added to force that behavior so if you set for us our own remove a few other things get pulled out of the image which in our use cases if we're not gonna use package management that's what we want so this is a example of a sort of custom district configuration I call it schooner I can explain that to somebody if they ask me later but it is very minimal just for like sort of ad-hoc thing the big takeaway here is I am basing off a POC but I don't change name stuff but I am setting muscle as the default see library and this is the sort of big win here is I'm actually setting a very minimal distribution features and so this cuts a quite a bit of stuff if you look at distribution features with fake - EE on this regular it's like three or four lines of stuff now a bunch of is is coming from this variable but just all these other variables like blue Z and pulseaudio and things like that which we're not gonna want any of that in our container image and these variables are used by the core image sort of functionality that the default image types in openembedded and so if you set these a few other things get pulled out so the init scripts and the unit manager and things like that so if you're gonna make your own image type that doesn't base on the core image you don't need to worry about these but if you want to making this with this default district configuration it's nice to actually have these defined to do what we want right so remember a little bit of that I'm actually gonna there's so many subsequent examples I actually use schooner comp when I'm building them so we've built our sort of Alpina like thing to see what we can do let's try and build a minimal app container just a single application it's dependencies so this is my base for that where I attempt to build as little as possible and so basically I do so you know sort of set the container type I am attacking on X for because I want to use system the end spawn at one point but here I'm actually turning off all the image features by default bill languages support and I'm disabling recommendations which is a mechanism where you might not have a hard dependency on something but you can recommend that it be installed for utility you can turn that off and then it makes if you need something you have to explicitly say you want it and then I actually define I would you want things like the default directory structure so like Etsy and dev and things like that so they're available for things to be mounted on them the container tools that's bass files bass passwd gives us that sort of initial sort of blank you know or whatever default passwd for things to actually be able to look up you IDs and stuff and then net based on I think taxing Etsy host sort of default values and then I also sort of hook up the my sort of fill fill in for now my scheme for actually making sure that the volatile directory stuff is hanging so if we say that's our template and then I want to build something with that so my first example here of doing that is I actually build a minimal image with light httpd and so I pull in the previous image definition and add to it and so as the comment says light httpd actually requires been SH when you start poking around and you trying to run it it actually execs some things and needs a shell so that previous image you will build you won't actually get a shell in it so we have to add it to get it and because we disabled recommendations we have to explicitly add a couple things that were sort of recommended interestingly when you build an image without those two things and go to run light hd-dvd it fails because the default configuration refers to them so that's maybe an interesting thing I need to poke at somebody because that sort of goes beyond recommendations if it doesn't actually start without them I'd almost say that's more of an AR depends as opposed to a recommendations but what does this produce a very small image it only has these packages in it three of them are the ones we specified in our image template and then basically we get just the dependencies muscle for the C library and then like Lib crypto and live adder basically and I believe a PC re one I think is also gets pulled in by muscle and it's quite small it's just the application so let's try something a little more substantial another web server engine X it basically is very similar I mean that's the goal of having that templated app a container image BB file so we can just basically image install plus equals so that gets us an image with just that I think I am getting close to running at the time but so a couple notes there Bosch might get pulled in does a mechanism that looks for scripts and might pull it in so let's be aware that if something is actually gonna exact things you need a busybox and because posts all scripts get disabled you may have to do some tweaking so I'll try to quickly run through the sandboxing example because this is some of the more interesting bits that I haven't seen too many people talk about so we'd be building container images with this previous examples and you know so you can dock or import them you could run docker compose or some of the other OCI image tools and then you actually on your target that you've built the core into the image you could fetch them or other tools run C but what if one actually do a factory image that already has some of those like like HTTP or similar type of app container images how do we do that so right now it's a bit constrained system to end spawn it seems doable from experiments the other things it's not really obvious how to do you except maybe doing an image for the target device that used a post install script to do an import of the image that we could sort of orchestrate that so those two approaches the simple ich one yet jeremy rosen talked about at embedded recipes last month he gave me somewhat similar talk and so it basically is sort of straightforward but has some restrictions on machine distro and Lipsy configuration between the container and the target image as well I sort of did some other sort of concurring this multi config feature and newer versions of openembedded gives us some more flexibility where we can actually mix and match between the container build and the host built multi gig if you want to look that up this is URL here to the documentation and this note that multi cue fake dependencies are a somewhat recent addition and the newest version have open but embedded and so I'll mention later this some things happen all right so I've come down to a few minutes so here's my simple example so we sort of follow on I make a recipe to package up the image that we previously built so this is the app container image light HDB httpd I'm using it as a source file and I mean basically including it into the target root filesystem and then I have an AR depends on system D container because that's the tool that that package includes the tools we're gonna use for system D n spa so this is interesting thing where that's pretty small it's required if you bitbake this it'll build the image then run this recipe to basically stick the image that was built into a package and then that package will go into the root files and to use it it's as easy as this you make a host image definition and just image install you just add that recipe to it and when you bitbake this you end up with the root filesystem that has the container already in it which is pretty straightforward I mean it's not it's interesting it's a what's a hack is interesting I was interesting to see it and when I looked at Jeremy slides to see if I had any point in giving this talk after his but I did find that the multi config stuff he hadn't really talked about because it's quite new so if you look at Jeremy slides from embedded recipes he sort of walked through that example I used the container class in mind but multi config is a system where you can actually figure for different basically it's almost like a different local comps it's essentially so in your local coffee to set BB multi config to list the different config types and then you make a multi config directory and put a separate comm file for each of them so in this one it simply to hopefully quickly run through this I am basically defining the host has system D that's what these options do and the container I'm using my schooner distribution class or distro definition and my machine type and I have I'm actually sending it so that when the container stuff builds it goes into a different temp directory and so here's our multi config version and this is the magic here so this dependency actually makes it that our do install in this recipe doesn't run until the other configurations build of the container image has completed and so if you look at the documentation this is the pretty much almost the example that's in the documentation of one image relying on another image and this also works it does give sort of the same result the build process looks a little different than the output from bitbake and this is we actually accomplish things a little differently in our image the this is the MC depend multi fig multi config depends so this is the dependency that we're actually defining and this is an image class we're not actually using a recipe to grab the image this is and actually we're doing it in the image definition and this is the example that's in the documentation for openembedded right now and this works the other approach when I actually try and make a recipe to pull the other image with the multi config dependency it fails so that's something I started poking I talked to Richard about yesterday the open embedded maintainer I have to generate some log files and we have to sit down and work out what's going on and I mentioned I had a set tempter that is probably the summoning pad ability between muscle and G let's see building the two images at the same time ideally it shouldn't have to be required that you set tempter and then one of the drawbacks is that I have to sort of dig down from the top level to get at the image it'd be nice if I get to say tempter and deployed her and avoid having to specify all this so it's sort of a work in progress and that's my talk I sort of rushed through there trying to fit it all in I don't think I actually have much in the way of time for questions it is the coffee break that's a good point so if anyone has a question feel free unless you're gung ho to go for coffee the terminology right so yeah thank you uh the Linux dummy are you using the upstream linic dummy from a week or I am yes okay I just paste it's linked to a slightly longer version that installs two headers so external modules don't fail which is useful for well non container I don't care I know but a package like lighty can recommend an ipv6 module which will trigger kind of thing so I needed it for my content okay all right that's good to know are you gonna upstream that maybe and another question you derived schooner from pokey and overrode basically everything pokey does so well it's a bunch of other stuff in Pocky I didn't feel like trying to fit on a slide if I was doing it for real if you were doing it for real you prob you actually do a full file that's what he's getting at you wouldn't actually require Pocky comp you just actually fill in there's like another 20 lines of stuff I had to play I think you can just lead them to depend on what a week or sets us defaults because the faults work nowadays yes that's this is a Linux Foundation talks so so Yocto project is the approved brush well not proves too strongly but it's the it's the sort of linux foundation back projects thank you but any other questions if you can come up to the mic or hopefully so one of the things you said winning as a challenge of containers was the library updates can affect multiple containers so how does this address that it has sort of the same problem although in this case my a sort of expectation is you'd be building all this yourself so it's very easy to script builds with with you know bitbake and openembedded is that my imagination would be you'd pull the update and you'd run your build process and you'd recreate all your container images in one go it wouldn't be stuck billing out and tweaking docker files potentially and doing you know compose or you know whatever you would do to actually regenerate all your different containers this might get it all in one shot potentially if you've are you know but the care in to set up your build process right because the tools this is all command-line tools and it's all pretty much bitbake this image and so it's pretty scalable to do builds now the the didn't really mention it but the state cash for openembedded if you're making these container images and you're only making like a change of adding a package to an app container the builds are gonna be actually quite quick after you get the initial tool chain all that stuff built so you're just tweaking one library and then this do bitbake of like these bunch of different images it'll probably very quick so there might be a benefit yes sir yeah one last thing I wanted to just your your open question about if you wait about two to three weeks meta virtualization will have a BB class they build the oh yeah oh CI containers so what's your how did you cook up a scheme it's using and it's using the tools that are in there already yeah none Maki and all the things that are there already so that's good yeah we're and if you jump on the meta virtualization mailing list you can find her too so you and you end up with a docker native no OCIO CI compliant so you can write us run to your docker oh yeah alright oh that's good here thank you thank you Bruce anybody else well thank you very much [Applause]

Channel: The Linux Foundation

Views: 5,030

Keywords: Open source, linux, kubectl, kubernetes, kernel, Red Hat, blockchain, Cloud, OpenFaaS, CI/CD Pipeline, Scaling, security, Zephyr, kubeadm, IoT, Machine Learning, Kubeflow, Embedded System, Cisco, Yocto Project, AI, Data, Edge, Cloud-native, Buildroot, FfDL, OpenCV, U-Boot, Edge Computing, VMWare, Microsoft, Microservices, container, virtualization, NVDIMM, OpenOCD, DevOps, KVM, eBPF, XDP, Hyperledger Sawtooth

Id: OSyLoHYxGLQ

Length: 50min 46sec (3046 seconds)

Published: Thu Oct 25 2018