85 lines
		
	
	
		
			2.6 KiB
		
	
	
	
		
			ReStructuredText
		
	
	
	
			
		
		
	
	
			85 lines
		
	
	
		
			2.6 KiB
		
	
	
	
		
			ReStructuredText
		
	
	
	
************************************
 | 
						|
Building and Using a Container Image
 | 
						|
************************************
 | 
						|
 | 
						|
Building a container image based on CoreOS is really easy. You have to set
 | 
						|
the machine to either of the following value in the `local.conf` file:
 | 
						|
 | 
						|
- container-x64
 | 
						|
- container-arm64
 | 
						|
- container-arm32
 | 
						|
 | 
						|
.. hint::
 | 
						|
 | 
						|
    The machine can also be overwriting from the shell using
 | 
						|
    `MACHINE=<machine> bitbake`
 | 
						|
 | 
						|
Then you can generate any image by running:
 | 
						|
 | 
						|
.. code-block:: sh
 | 
						|
 | 
						|
    $ bitbake <image>
 | 
						|
 | 
						|
As an example, you can build the `coreos-image-minimal` as an OCI container
 | 
						|
for AMD64 machine with the following command:
 | 
						|
 | 
						|
.. code-block:: sh
 | 
						|
 | 
						|
    $ MACHINE=container-x64 bitbake coreos-image-minimal
 | 
						|
 | 
						|
 | 
						|
This will generate a container tarball in the tar.gz format.
 | 
						|
 | 
						|
If you are using `podman`, you can import the container with:
 | 
						|
 | 
						|
.. code-block:: sh
 | 
						|
 | 
						|
    $ cd $BUILDDIR/tmp/deploy/images/container-x64
 | 
						|
    $ podman import coreos-image-container-container-x64.tar.bz2
 | 
						|
    Getting image source signatures
 | 
						|
    Copying blob 46c0b1c53d42 [--------------------------------------] 0.0b / 0.0b
 | 
						|
    Copying config 051856498a done  
 | 
						|
    Writing manifest to image destination
 | 
						|
    Storing signatures
 | 
						|
    051856498a59e0ae6349492539efaf915a33dd73e7a54ce9683b0414d1481fae
 | 
						|
 | 
						|
Then you can use start any program included in the image with:
 | 
						|
 | 
						|
.. code-block:: sh
 | 
						|
 | 
						|
    $ podman run <PODMAN_ARGS> <IMAGE_ID> <COMMAND> <COMMAND_ARGS>
 | 
						|
 | 
						|
To run an interactive shell, you can use:
 | 
						|
 | 
						|
.. code-block:: sh
 | 
						|
 | 
						|
    $ podman run -i <IMAGE_ID> ash --i
 | 
						|
    / # 
 | 
						|
 | 
						|
The `<IMAGE_ID>` should be copied from the output of `podman import`. In this
 | 
						|
example, it was
 | 
						|
`051856498a59e0ae6349492539efaf915a33dd73e7a54ce9683b0414d1481fae`.
 | 
						|
 | 
						|
You are now inside the container, try the following command:
 | 
						|
 | 
						|
.. code-block:: sh
 | 
						|
 | 
						|
    / # cat /etc/os-release
 | 
						|
    ID=belden-coreos
 | 
						|
    NAME="Belden CoreOS"
 | 
						|
    VERSION="0.0.1-feat/oci-image+75cf54e4b54b713d8ebeafddd122aeb615715ef9 (kirkstone)"
 | 
						|
    VERSION_ID=0.0.1-feat/oci-image-75cf54e4b54b713d8ebeafddd122aeb615715ef9
 | 
						|
    PRETTY_NAME="Belden CoreOS 0.0.1-feat/oci-image+75cf54e4b54b713d8ebeafddd122aeb615715ef9 (kirkstone)"
 | 
						|
    DISTRO_CODENAME="kirkstone"
 | 
						|
 | 
						|
.. note::
 | 
						|
 | 
						|
    Image generated using any container machines doesn't include the Linux
 | 
						|
    kernel neither many system component that are usually not used on a container
 | 
						|
    like SystemD or udev. This is done inside the machine configuration by
 | 
						|
    settings all the `VIRTUAL_RUNTIME_<component>` to an empty string.
 | 
						|
 | 
						|
    Any of these system component can be added to the image if needed, by adding
 | 
						|
    them by their real name (instead of using any `VIRTUAL_RUNTIME_` variables)
 | 
						|
    in the `IMAGE_INSTALL` variables.
 |