From 9d75c9401e05b30ce86b3627da651a1070af435d Mon Sep 17 00:00:00 2001 From: Gabriel Arakaki Giovanini Date: Sun, 30 Apr 2023 16:45:51 +0200 Subject: feat: New post about running alpine in memory --- content/posts/2023-04-30-using-data-mode-alpine.md | 156 +++++++++++++++++++++ 1 file changed, 156 insertions(+) create mode 100644 content/posts/2023-04-30-using-data-mode-alpine.md (limited to 'content/posts/2023-04-30-using-data-mode-alpine.md') diff --git a/content/posts/2023-04-30-using-data-mode-alpine.md b/content/posts/2023-04-30-using-data-mode-alpine.md new file mode 100644 index 0000000..d0e7623 --- /dev/null +++ b/content/posts/2023-04-30-using-data-mode-alpine.md @@ -0,0 +1,156 @@ +--- +title: "Running alpine in memory with data mode" +date: 2023-04-30 +tags: ['alpine', 'linux'] +--- + +# Local testing + +To facilitate iteration and testing of this setup, we can use `qemu` and for the +whole setup we will be using two disks: one for mounting the /var folder and +another for storing lbu files (more on that later). To create the two images, +follow these steps: + +```bash +qemu-img create -f qcow2 var.cow2 10G +qemu-img create -f qcow2 media.cow2 5G +``` + +Those images have arbitrary sizes and probably won't even required that much for +this setup so feel free to choose another size. + +Once you have created the images go to alpine download page[^1] and grab the +latest virtual image. + +We all of that we can now start the virtual machine + +```bash +qemu-system-x86_64 \ + -machine accel=kvm \ + -display gtk \ + -m 2048 \ + -boot d \ + -cdrom alpine-virt-3.17.3-x86_64.iso \ + -drive file=var.cow2,if=virtio \ + -drive file=media.cow2,if=virtio +``` + +For more info about what are those parameters head to `qemu` documentation[^2]. +Just pay attention to the `-boot d` option which will force cdrom to boot first +(more on that later as well). + +# Setting up environment + +Before we can run `setup-alpine` we need to mount a persistent media folder so +it can be picked up by the script and used to store the `lbu` files. To do so we +need to install some extra package that are not available in the live ISO. + +Run `setup-interfaces` to configure interfaces. The default values will do. +After that start the networking service `rc-service networking start`. Now we +have internet we can setup a repository. You could edit `/etc/apk/repositories` +directly but there is handy command for that already `setup-apkrepos`. Run it +and pick any option you see fit. I'd go for `f` but `1` also works. + +Now we can install some packages required for the remaining of the setup: + +```bash +apk add lsbkl e2fsprogs +``` + +`lsblk` is useful to identify devices and `e2fsprogs` will provide `ext4` +support. + +Run `lsblk` and will display the device we attached, e.g.: + +```bash +vda 253:0 0 10G 0 disk +vdb 253:0 0 5G 0 disk +``` + +Now let's format and mount `vdb` on `/media`. + +```bash +# formatting using ext4 +mkfs.ext4 /dev/vdb + +# creating target folder for mouting +# the name is arbitrary, feel free to choose another one +mkdir /media/vdb + +# mouting +mount -t ext4 /dev/vdb /media/vdb +``` + +To confirm if device is mounted you can run `df -h /media/vdb`, it shows the +size and which device is mounted on that folder. + +# Setting up alpine on data mode + +Now we can run `setup-alpine`. Choose whatever options fits your need up to the +point where it asks to choose the device. It may repeat some of the step we +already did but it is be fine. + +When it asks to choose a disks to use enter the name of disk, which, in this +particularly setup, is `vda`. Then it will ask to choose how you would like to +run alpine[^3], pick `data`. + +Now it will prompt to choose which media device we want to use for storing the +`lbu` files. By default it should the media folder we mounted in the previous +step, if not just enter `vdb`. Select place for cache. Default is fine. + +The cache folder is used to store the apk files we come to add. Since it does +not have internet access when booting it needs to store those extra package in +folder so later it can be restored. + +**Warning**, do not reboot now. We need to use `lbu` to make a backup of all +changes we did, otherwise everything will be lost. Take a careful read of the +`lbu` documentation[^4], it will provide the necessary information to understand +how `lbu` works. + +Run `lbu commit` to backup it. You can check the `apkvol` file stored in the +`/media/vdb/`. Now you changes as saved and you are good to reboot. + +The live ISO will look for `apkvol` files and try to restore it. That is why it +is required the ISO to be the first to boot. There is no boot info store +anywhere else since the one device is used to store `lbu` and the other one is +mount on `/var` so we use live ISO to boot and restore the state. + +You can check here[^5] how that is possible and here [^6] how we can expand that +idea and netboot using the apkvol to boot any machine to specific state. + +# Making changes + +After rebooting your system, you can now log into your fresh installation. You +can then install a new package, such as vim, using the command `apk add vim`. +However, if you reboot the system again, the vim package will be lost and you +will need to reinstall it. + +If you run `lbu status` will show what was changed and in this case +`/etc/apk/world`. The world file store all the package you have installed and +since you have added a new packaged it has been modified. `lbu +commit` to persist it. + +You can check the `/media/vdb/cache` folder to see that it has stored the vim +package and its dependencies. + +# Why /var? + +The /var folder is a directory in Linux that is used to store variable data +files as the contents of this folder can change by the OS. This folder contains +files that are not critical to the basic operation of the system, but are +instead used for tasks such as logging, spooling, and caching. For example +postgresql store all its data on the var folder allowing us to use a database on +data mode and still have its data persistent between boots. + +# In conclusion + +We can take advantage of speed boost provided by `tmpfs`, and we can still +restore the system state even if the computer is rebooted. The only thing to +keep in mind is to commit any changes made before rebooting ;). + +[^1]: https://alpinelinux.org/downloads/ +[^2]: https://www.qemu.org/docs/master/system/invocation.html +[^3]: https://wiki.alpinelinux.org/wiki/Installation +[^4]: https://wiki.alpinelinux.org/wiki/Alpine_local_backup +[^5]: https://bitfehler.srht.site/posts/2022-11-28_messing-with-your-initramfs---alpine-edition.html +[^6]: https://www.apalrd.net/posts/2022/alpine_pxe/ -- cgit v1.2.3