3 ms·

Kubevirt is great, but, I'm not sure why you wouldn't just run weechat inside a container. There's nothing so special about weechat that it wouldn't work and y

Kubevirt is great, but, I'm not sure why you wouldn't just run weechat inside a container. There's nothing so special about weechat that it wouldn't work and you can just exec into the container and attach to tmux. Running tmux/screen inside a container is definitely cursed, but, it works surprisingly well.

xena 2y ago
Author of the article here. One of the main reasons is that I want to update weechat without rebuilding the container, taking advantage of weechat's soft upgrade method: https://weechat.org/files/doc/weechat/stable/weechat_user.en.html#command_weechat_upgrade https://weechat.org/files/doc/weechat/stable/weechat_user.en... And at that point, it may as well just be a normal Ubuntu server.
- AdamJacobMuller 2y ago
  Ah I didn't know wechat could do that, but, I remember that from my irssi days. I would personally consider that a bit of an anti-pattern (I would always want to have software upgrades tied to the container) but that makes sense!
  - xena 2y ago
    As a long-time Docker-slonker I agree, however then that requires me to remember to upgrade the container images which means that it's harder to ensure that it's up to date. If you set up a cronjob to update the VMs packages and then a script that runs `/upgrade` on the weechat server every time the weechat package version changes, then you don't need to think.
    - fuero 2y ago
      Consider having Renovate handle this for you - using a git repo to apply your manifests will make it pull updated container images
    - AdamJacobMuller 2y ago
      I have this very easily setup to a set of simple commands which I can run to deploy new versions of packages. Basically 3 paths for: - things with well-maintained upstream helm charts (checks the latest version of the helm chart and updates helmfile) - things where I wrote a helm chart (checks for the latest container image and updates the values.yaml) - things where there is no (reasonable) public docker image, or my own software, where I have full CI/CD to build and deploy a new container image. Probably takes me 15 minutes a week to keep my two personal clusters fully up-to-date.
- tw04 2y ago
  So why not just make it a VM and skip k8s altogether?
  - xena 2y ago
    Because I already have a kubernetes cluster with distributed storage. This way makes it somewhat standard with the rest of my setup. In SRE things the real enemy is when parts are unique in ways that conflict with the normal way of doing things. Look up at the "unique/standard" comment above and then take a moment to think about it. It sounds absurd from the first read; but when you realize that it allows me to reuse the hardware I have and take advantage of the second order properties I've done, then it makes more sense.
    - bbkane 2y ago
      This is also why I design all my config files to use YAML. I've already got powerful tools to deal with its quirks (JSONSchema, yq, yamllint)
  - imtringued 2y ago
    Mostly because VM tooling is stuck in the past.
- okasaki 2y ago
  You can do that in a container, no need for a VM. docker run -itd ubuntu:24.04 ... docker exec -it df36 /bin/bash ... root@df365a3d2257:/# apt update ... root@df365a3d2257:/# apt upgrade ...
  - xena 2y ago
    Then when the container gets rescheduled I'm suddenly running the old version of weechat
    - znpy 2y ago
      Wouldn’t an init container in the pod definition help here? Nice article btw!
- kristianpaul 2y ago
  Why not use Persistent Volumes and Nix container?

xena 2y ago

Author of the article here. One of the main reasons is that I want to update weechat without rebuilding the container, taking advantage of weechat's soft upgrade method: https://weechat.org/files/doc/weechat/stable/weechat_user.en.html#command_weechat_upgrade https://weechat.org/files/doc/weechat/stable/weechat_user.en... And at that point, it may as well just be a normal Ubuntu server.

AdamJacobMuller 2y ago
Ah I didn't know wechat could do that, but, I remember that from my irssi days. I would personally consider that a bit of an anti-pattern (I would always want to have software upgrades tied to the container) but that makes sense!
- xena 2y ago
  As a long-time Docker-slonker I agree, however then that requires me to remember to upgrade the container images which means that it's harder to ensure that it's up to date. If you set up a cronjob to update the VMs packages and then a script that runs `/upgrade` on the weechat server every time the weechat package version changes, then you don't need to think.
  - fuero 2y ago
    Consider having Renovate handle this for you - using a git repo to apply your manifests will make it pull updated container images
  - AdamJacobMuller 2y ago
    I have this very easily setup to a set of simple commands which I can run to deploy new versions of packages. Basically 3 paths for: - things with well-maintained upstream helm charts (checks the latest version of the helm chart and updates helmfile) - things where I wrote a helm chart (checks for the latest container image and updates the values.yaml) - things where there is no (reasonable) public docker image, or my own software, where I have full CI/CD to build and deploy a new container image. Probably takes me 15 minutes a week to keep my two personal clusters fully up-to-date.
tw04 2y ago
So why not just make it a VM and skip k8s altogether?
- xena 2y ago
  Because I already have a kubernetes cluster with distributed storage. This way makes it somewhat standard with the rest of my setup. In SRE things the real enemy is when parts are unique in ways that conflict with the normal way of doing things. Look up at the "unique/standard" comment above and then take a moment to think about it. It sounds absurd from the first read; but when you realize that it allows me to reuse the hardware I have and take advantage of the second order properties I've done, then it makes more sense.
  - bbkane 2y ago
    This is also why I design all my config files to use YAML. I've already got powerful tools to deal with its quirks (JSONSchema, yq, yamllint)
- imtringued 2y ago
  Mostly because VM tooling is stuck in the past.
okasaki 2y ago
You can do that in a container, no need for a VM. docker run -itd ubuntu:24.04 ... docker exec -it df36 /bin/bash ... root@df365a3d2257:/# apt update ... root@df365a3d2257:/# apt upgrade ...
- xena 2y ago
  Then when the container gets rescheduled I'm suddenly running the old version of weechat
  - znpy 2y ago
    Wouldn’t an init container in the pod definition help here? Nice article btw!
kristianpaul 2y ago
Why not use Persistent Volumes and Nix container?