Install Jellyfin server with Ansible
Install Jellyfin server with Ansible to set up your own media streaming service in an automated manner. Download the role to install your own media server. This post does not explain Jellyfin itself, it is only about to install it with Ansible.
Running Home Assistant on Kubernetes
Running Home Assistant on Kubernetes. It is about time to put your IoT devices under control. Everything runs off the cloud on my on-premise Kubernetes. Clean and secure.
This blog will not cover what Home Assistant is or how Kubernetes works. I assume you already have that covered.
Deploy Elasticsearch stack with podman and Ansible
Deploy Elasticsearch stack with podman and Ansible. Halfway on the road towards complete automation. But without the necessity of a complex orchestration tool. Somewhere between pets and cattles.
Continue reading Deploy Elasticsearch stack with podman and Ansible
Install OpenSUSE MicroOS in KVM with Ignition
Install OpenSUSE MicroOS in KVM with Ignition. A step-by-step guide to provision container specific OS instances really fast.
About OpenSUSE MicroOS
I needed a container specific OS since I converted my docker-compose services to pods with Podman. Fedora CoreOS looks promising. However I have been using OpenSUSE for years, so it was convenient for me to try MicroOS which is derived from Tumbleweed.
These are the features which I like the most.
- Automatic transactional updates. If you do not like the result, then you can switch back to the previous snapshot.
- Up to date software versions. Especially for software like Podman which improves rapidly.
- A minimal environment specially designed for container workloads. It has greatly reduced attack surfaces and improved performance.
Install OpenSUSE MicroOS in KVM with Ignition
There are documentations about MicroOS, but I could not find a complete guide about how to install OpenSUSE MicroOS in KVM. Also its Ignition guide directly redirects to CoreOS’s git repo for documentation. The information is there but putting it together takes time.
As I already managed to do it then why not to share it? 🙂
In my guide I will use virsh (libvirt) and virt-install (virt-manager) to provision headless MicroOS VMs based on the downloadable KVM images they made available. Both tools are higher lever APIs to KVM / QEMU.
Installing libvirt to make using QEMU easy
OpenSUSE has a package pattern for turning your OS into a virtualization host. Following the Virtualization Guide will definitely help. But if you do not want to read it all then just run the following command.
zypper in -t pattern kvm_server kvm_tools
Should you want to read more about managing virtual machines with libvirt then there is a documentation for that too. I will not go into details this time.
Downloading and verify installation media of MicroOS
Once the tools are ready then download the installation media and verify the checksum and signature.
# cd /var/lib/libvirt/images
# curl -LO http://download.opensuse.org/tumbleweed/appliances/openSUSE-MicroOS.x86_64-ContainerHost-kvm-and-xen.qcow2
# curl -LO http://download.opensuse.org/tumbleweed/appliances/openSUSE-MicroOS.x86_64-ContainerHost-kvm-and-xen.qcow2.sha256
# curl -LO http://download.opensuse.org/tumbleweed/appliances/openSUSE-MicroOS.x86_64-ContainerHost-kvm-and-xen.qcow2.sha256.asc
Note that sha256 checksum and signature was made for a snapshot whose name is different from the file we downloaded, though the content is the same. Probably the other files on their webserver are just symbolic links.
# sha256sum openSUSE-MicroOS.x86_64-ContainerHost-kvm-and-xen.qcow2
# gpg --search-keys B88B2FD43DBDC284
# gpg --recv-keys 0x22C07BA534178CD02EFE22AAB88B2FD43DBDC284
# gpg --verify openSUSE-MicroOS.x86_64-ContainerHost-kvm-and-xen.qcow2.sha256.asc
Creating Ignition configuration for VM
Ignition expect its configuration to be in JSON. However one just not create a JSON file by hand. But creates a YML file and convert it with semantic checks (and some boilerplate) to JSON by using CoreOS’s fcct. Here is my example. It is pretty straight forward.
variant: fcos
version: 1.0.0
passwd:
users:
- name: root
ssh_authorized_keys:
- ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDHj2D8PAxz0MKV9UJ8dxavlVzdAvMBrfGp38sj4q/aRbkcuYVNHAQh+xXHI0VcPEtu9rqZbvqfmQt0DFhsdf938W6r3y6mLp4+6KIDgb4Jj2B3zlzBIF0haAFi/GZAp4dh4uuhHsVvZGqsdqCglxUnIPb+i8IyYA8GGU+3IOgRfjjtpMfDJcWZTzGm56yDsBYORX3EckkGcWTN4/oW0SKWoO9zf/887/CvVZF/0V7corEAdMyTCiSSqqUjIDLAZpCMU4czadZop7cvVjGT6WLmyGDuTBruvjsMwxYA/OMAZrUuOEoAW0bf/QZRZ4tO7ku+o0oqwca5uwVbuouAFovJ root@example
password_hash: "$1$salt$qJH7.N4xYta3aEG/dfqo/0"
storage:
files:
- path: /etc/sysconfig/network/ifcfg-eth0
mode: 0600
overwrite: true
contents:
inline: |
BOOTPROTO='static'
STARTMODE='auto'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR='192.168.0.10/24'
MTU=''
NAME=''
NETWORK=''
REMOTE_IPADDR=''
ZONE=public
- path: /etc/sysconfig/network/routes
mode: 0644
overwrite: true
contents:
inline: |
default 192.168.0.254 - -
- path: /etc/hostname
mode: 0644
overwrite: true
contents:
inline: |
example.com
Please note that on OpenSUSE you cannot just provide static DNS information by overwriting /etc/resolv.conf. Because the content of /etc/resolv.conf is managed by netconfig. And it configuration file bigger than optimal to include it in a YML file. Though you can configure it manually after the first run.
Once you are ready, put the contents into config.fcc and convert it to JSON by using fcct.
# podman run -i --rm quay.io/coreos/fcct:release --pretty --strict < config.fcc > config.ign
Create a KVM host with virt-install
The Ignition file can be specified via QEMU command line. Adjust the specification of the VM according to your needs.
# virt-install --import --connect qemu:///system --name example \
--ram 1024 --vcpus 1 \
--disk size=20,backing_store=/var/lib/libvirt/images/openSUSE-MicroOS.x86_64-ContainerHost-kvm-and-xen.qcow2,bus=virtio \
--os-variant=opensusetumbleweed \
--network bridge=br0,model=virtio \
--noautoconsole \
--graphics spice,listen=127.0.0.1 \
--qemu-commandline="-fw_cfg name=opt/com.coreos/config,file=/path/to/config.ign"
No you have just installed OpenSUSE MicroOS in KVM with Ignition. Enjoy.
Managing VM with Virsh
Virsh is another tool to manage your VMs. Here I provide some examples I frequently use. They could be useful.
Console access
You can attach to the serial console of the VM with the following command.
# virsh console example
Disconnecting from Virsh console is possible with SHIFT+5.
Remote console access
Remote access to the console is possible with Spice. If you are not in production then you can easily access the remote Spice port without TLS via SSH port forward.
Delete virtual machines
This can be useful when you are not satisfied with the result and want to start over from scratch. Storage files are not automatically deleted.
# virsh dumpxml --domain example | grep 'source file'
<source file='/var/lib/libvirt/images/example.qcow2'/>
<source file='/var/lib/libvirt/images/openSUSE-MicroOS.x86_64-ContainerHost-kvm-and-xen.qcow2'/>
# virsh destroy example
# virsh undefine example
# rm -f /var/lib/libvirt/images/example.qcow2
I hope you will enjoy your shiny new container host. 🙂
Managing Podman pods with pods-compose
Managing Podman pods with pods-compose makes your move to Podman easier. I already converted my docker-compose services to pods with Podman, however I really missed some features, up until now. Let’s meet pods-compose.
Missing features of Podman
As soon as I managed to convert docker-compose services to pods I realized that managing them will be not as easy as it was with docker-compose. I faced with the following problems.
- There is no autostart for pods and containers. Of course you can generate systemd service units for all components but managing them is not easy without an automation tool. There are separate service files for each pod and container.
- For updates you might have to stop, remove, recreate everything from scratch, unless you script it. There is no ‘up‘, ‘down‘ or ‘build‘ features like you have with docker-compose.
- There is no single point of configuration which I could use to describe all the pods and containers. I could write and maintain Kubernetes YAML files, but that’s even harder than using the CLI syntax I am already familiar with.
I needed a tool which makes managing Podman pods easier. podman-compose looked promising but it did not really work for me and I also did not like its CLI interface. So I decided to write my own tool.
Design goals of pods-compose
I did not want to put a lot of effort into this. I only wanted the following additional abilities.
- Be able to automatically start and stop all pods and containers upon reboot.
- Tear down existing pods at once.
- Create pods and containers from a description at once.
- Build all the images I define with a single command.
I did not want to rely on docker-compose’s YAML format. Intentionally there is no support for using an existing compose configuration. Although I was already familiar with that format, I wanted a complete migration not just a partial one.
Managing Podman pods with pods-compose
As a kickstart, let’s get a glimpse into the similarities between pods-compose and docker-compose.
pods-compose | docker-compose | |
Deploy pod(s) | –up [POD] | up [SERVICE] |
Tear down pod(s) | –down [POD] | down [SERVICE] |
Start pod(s) | –start [POD] | start [SERVICE] |
Stop pod(s) | –stop [POD] | stop [SERVICE] |
Restart pod(s) | –restart [POD] | restart [SERVICE] |
Build all container images | –build | build |
Status of pods and containers | –ps | ps |
Generate Kubernetes Pod YAML(s) | –generate |
Autostart pods and containers
Podman can generate systemd units for pods and containers. However there will be many of them, making it hard to overview and maintain it. Because pods-compose takes care of starting and stopping pods with a single command line option, I could create a single systemd service file instead of many.
The install script will deploy that systemd service file for pods-compose. Enabling it makes your pods and containers to start automatically upon reboot. And of course gracefully stop before the system halts.
Further details can be found in the readme of pods-compose.
Things you still have to do manually
Creating containers at least first time is a manual procedure. People usually start with ‘docker run’ commands then once the result looks okay then will create a docker-compose YAML.
This will not change with pods-compose. You still have to create your pods and containers with ‘podman run’. However you do not have to create any YAML files. The tool will create them for you.
Luckily podman CLI syntax is almost the same as docker’s, so it is easy to make progress fast.
The other part is defining which image should be built by pods-compose. Because this information cannot be set in Kubernetes YAML files, you can use pods-compose‘s INI formatted configuration file to define the TAG and the CONTEXT of images. As a result, pods-compose will build all the images for you.
Final words
Let me know if you are still missing some features you would love to see implemented in pods-compose. Also please share if you liked it.