0.5.1+1.6.3 (#14)

* update Longhorn to v1.6.3

* update .yamllint

* fix ansible-lint issues

* update Molecule test

* fix Molecule verify

Author: githubixx

.yamllint

@@ -8,5 +8,12 @@ rules:
   line-length:
     max: 300
     level: warning
-
   comments-indentation: disable
+  comments:
+    min-spaces-from-content: 1
+  braces:
+    min-spaces-inside: 0
+    max-spaces-inside: 1
+  octal-values:
+    forbid-implicit-octal: true
+    forbid-explicit-octal: true

CHANGELOG.md

@@ -5,13 +5,26 @@ SPDX-License-Identifier: GPL-3.0-or-later
 
 # Changelog
 
+## 0.5.1+1.6.3
+
+- update Longhorn to `v1.6.3`
+- update `.yamllint`
+- update Molecule test
+
+Further reading:
+
+- [Longhorn v1.6.3 Release Notes](https://github.com/longhorn/longhorn/releases/tag/v1.6.3)
+- [Upgrading from v1.6.x (< v1.6.3) or v1.5.x](https://longhorn.io/docs/1.6.3/deploy/upgrade/longhorn-manager/)
+- [Node Maintenance and Kubernetes Upgrade Guide](https://longhorn.io/docs/1.6.3/maintenance/maintenance/)
+
 ## 0.5.0+1.6.1
 
 This is a major release update of Longhorn. Please read [Longhorn Important Notes](https://longhorn.io/docs/1.6.1/deploy/important-notes/) before upgrading!
 
 Further reading:
 
 - [Longhorn v1.6.1 Release Notes](https://github.com/longhorn/longhorn/releases/tag/v1.6.1)
+- [Upgrading from v1.6.x (< v1.6.3) or v1.5.x](https://longhorn.io/docs/1.6.3/deploy/upgrade/longhorn-manager/)
 - [Node Maintenance and Kubernetes Upgrade Guide](https://longhorn.io/docs/1.6.1/maintenance/maintenance/)
 
 Other updates:

README.md

@@ -9,7 +9,7 @@ This Ansible role is used in my blog series [Kubernetes the not so hard way with
 
 ## Versions
 
-I tag every release and try to stay with [semantic versioning](http://semver.org). If you want to use the role I recommend to checkout the latest tag. The master branch is basically development while the tags mark stable releases. But in general I try to keep master in good shape too. A tag `0.5.0+1.6.1` means this is release `0.5.0` of this role and it contains Longhorn chart version `1.6.1` (which normally is the same as the Longhorn version itself). If the role itself changes `X.Y.Z` before `+` will increase. If the Longhorn chart version changes `X.Y.Z` after `+` will increase too. This allows to tag bugfixes and new major versions of the role while it's still developed for a specific Longhorn release.
+I tag every release and try to stay with [semantic versioning](http://semver.org). If you want to use the role I recommend to checkout the latest tag. The master branch is basically development while the tags mark stable releases. But in general I try to keep master in good shape too. A tag `0.5.1+1.6.3` means this is release `0.5.1` of this role and it contains Longhorn chart version `1.6.3` (which normally is the same as the Longhorn version itself). If the role itself changes `X.Y.Z` before `+` will increase. If the Longhorn chart version changes `X.Y.Z` after `+` will increase too. This allows to tag bugfixes and new major versions of the role while it's still developed for a specific Longhorn release.
 
 ## Requirements
 
@@ -37,7 +37,7 @@ See [CHANGELOG.md](https://github.com/githubixx/ansible-role-longhorn-kubernetes
 
 ```yaml
 # Helm chart version
-longhorn_chart_version: "1.6.1"
+longhorn_chart_version: "1.6.3"
 
 # Helm release name
 longhorn_release_name: "longhorn"
@@ -176,13 +176,13 @@ longhorn_label_nodes: false
 
 ### Longhorn documentation
 
-Before you start installing Longhorn you REALLY want to read the [The Longhorn Documentation](https://longhorn.io/docs/1.6.1/)! As data is the most valuable thing you can have you should understand how Longhorn works and don't forget to add backups later ;-). Esp. have a look at the [best practices](https://longhorn.io/docs/1.6.1/best-practices/).
+Before you start installing Longhorn you REALLY want to read the [The Longhorn Documentation](https://longhorn.io/docs/1.6.3/)! As data is the most valuable thing you can have you should understand how Longhorn works and don't forget to add backups later ;-). Esp. have a look at the [best practices](https://longhorn.io/docs/1.6.3/best-practices/).
 
 ### Helm chart values
 
-That said: The first thing to do is to check `templates/longhorn_values_default.yml.j2`. This file contains the values/settings for the Longhorn Helm chart that are partly default anyways (just to avoid that someone changes the defaults) or different to the default ones which are located [here](https://github.com/longhorn/longhorn/blob/v1.6.1/chart/values.yaml). All settings can be found in the [Settings Reference](https://longhorn.io/docs/1.6.1/references/settings/).
+That said: The first thing to do is to check `templates/longhorn_values_default.yml.j2`. This file contains the values/settings for the Longhorn Helm chart that are partly default anyways (just to avoid that someone changes the defaults) or different to the default ones which are located [here](https://github.com/longhorn/longhorn/blob/v1.6.3/chart/values.yaml). All settings can be found in the [Settings Reference](https://longhorn.io/docs/1.6.3/references/settings/).
 
-To use your own values just create a file called `longhorn_values_user.yml.j2` and put it into the `templates` directory. Then this Longhorn role will use that file to render the Helm values. You can use `templates/longhorn_values_default.yml.j2` as a template or just start from scratch. As mentioned above you can modify all settings for the Longhorn Helm chart that are different to the default ones which are located [here](https://github.com/longhorn/longhorn/blob/v1.6.1/chart/values.yaml).
+To use your own values just create a file called `longhorn_values_user.yml.j2` and put it into the `templates` directory. Then this Longhorn role will use that file to render the Helm values. You can use `templates/longhorn_values_default.yml.j2` as a template or just start from scratch. As mentioned above you can modify all settings for the Longhorn Helm chart that are different to the default ones which are located [here](https://github.com/longhorn/longhorn/blob/v1.6.3/chart/values.yaml).
 
 ### Render and verify deployment manifests
 
@@ -218,15 +218,15 @@ To check if everything was deployed use the usual `kubectl` commands like `kubec
 
 ### Update/upgrade
 
-As Longhorn gets updates/upgrades every few weeks/months the role also can do upgrades. For updates/upgrades (esp. major upgrades) have a look at `tasks/upgrade.yml` to see what's happening before, during and after the update. In general this Ansible role does what's described in [Upgrade with Helm](https://longhorn.io/docs/1.6.1/deploy/upgrade/longhorn-manager/#upgrade-with-helm) in the [Upgrading Longhorn Manager](https://longhorn.io/docs/1.6.1/deploy/upgrade/longhorn-manager/) documentation. So in this step only the Longhorn Manager gets updated. After Ansible applied the update/upgrade wait till all Longhorn Pods are ready again.
+As Longhorn gets updates/upgrades every few weeks/months the role also can do upgrades. For updates/upgrades (esp. major upgrades) have a look at `tasks/upgrade.yml` to see what's happening before, during and after the update. In general this Ansible role does what's described in [Upgrade with Helm](https://longhorn.io/docs/1.6.3/deploy/upgrade/longhorn-manager/#upgrade-with-helm) in the [Upgrading Longhorn Manager](https://longhorn.io/docs/1.6.3/deploy/upgrade/longhorn-manager/) documentation. So in this step only the Longhorn Manager gets updated. After Ansible applied the update/upgrade wait till all Longhorn Pods are ready again.
 
-By default the Longhorn volume engines are NOT upgraded automatically. That means in the `Volumes` overview of the Longhorn UI one needs to click on the burger menu in the `Operation` column and run `Upgrade Engine`. To make yourself live easier, **make sure** that all volumes are in `Healthy` state before you upgrade anything. If you want to avoid this manual task of upgrading the volumes to the latest engine version you can set `Concurrent Automatic Engine Upgrade Per Node Limit` to `1` e.g. in `Settings / General` in the Longhorn UI. This setting controls how Longhorn automatically upgrades volumes' engines after upgrading Longhorn manager. The value of this setting specifies the maximum number of engines per node that are allowed to upgrade to the default engine image at the same time. If the value is `0`, Longhorn will not automatically upgrade volumes' engines to default version. For further information see [Automatically Upgrading Longhorn Engine](https://longhorn.io/docs/1.6.1/deploy/upgrade/auto-upgrade-engine/). If you want to do the volume engine upgrade manually have a look at [Manually Upgrading Longhorn Engine](https://longhorn.io/docs/1.6.1/deploy/upgrade/upgrade-engine/)
+By default the Longhorn volume engines are NOT upgraded automatically. That means in the `Volumes` overview of the Longhorn UI one needs to click on the burger menu in the `Operation` column and run `Upgrade Engine`. To make yourself live easier, **make sure** that all volumes are in `Healthy` state before you upgrade anything. If you want to avoid this manual task of upgrading the volumes to the latest engine version you can set `Concurrent Automatic Engine Upgrade Per Node Limit` to `1` e.g. in `Settings / General` in the Longhorn UI. This setting controls how Longhorn automatically upgrades volumes' engines after upgrading Longhorn manager. The value of this setting specifies the maximum number of engines per node that are allowed to upgrade to the default engine image at the same time. If the value is `0`, Longhorn will not automatically upgrade volumes' engines to default version. For further information see [Automatically Upgrading Longhorn Engine](https://longhorn.io/docs/1.6.3/deploy/upgrade/auto-upgrade-engine/). If you want to do the volume engine upgrade manually have a look at [Manually Upgrading Longhorn Engine](https://longhorn.io/docs/1.6.3/deploy/upgrade/upgrade-engine/)
 
-Of course you should consult Longhorn's [upgrade guide](https://longhorn.io/docs/1.6.1/deploy/upgrade/) (the link is for upgrading to Longhorn `v1.6.1`) to check for major changes and stuff like that before upgrading. Now is also a good time to check if the backups are in place and if the backups are actually valid ;-)
+Of course you should consult Longhorn's [upgrade guide](https://longhorn.io/docs/1.6.3/deploy/upgrade/) (the link is for upgrading to Longhorn `v1.6.3`) to check for major changes and stuff like that before upgrading. Now is also a good time to check if the backups are in place and if the backups are actually valid ;-)
 
-After consulting Longhorn's [upgrade guide](https://longhorn.io/docs/1.6.1/deploy/upgrade/) you basically only need to change `longhorn_chart_version` variable e.g. from `1.5.4` to `1.5.5` for a patch release or from `1.5.5` to `1.6.1` for a major upgrade. And of course the Helm values need to be adjusted for potential breaking changes (if any are mentioned in the upgrade guide e.g.). But please remember that MOST settings shouldn't be changed anymore via the Helm values file but via the Longhorn UI in `Settings / General` e.g.
+After consulting Longhorn's [upgrade guide](https://longhorn.io/docs/1.6.3/deploy/upgrade/) you basically only need to change `longhorn_chart_version` variable e.g. from `1.5.4` to `1.5.5` for a patch release or from `1.5.5` to `1.6.3` for a major upgrade. And of course the Helm values need to be adjusted for potential breaking changes (if any are mentioned in the upgrade guide e.g.). But please remember that MOST settings shouldn't be changed anymore via the Helm values file but via the Longhorn UI in `Settings / General` e.g.
 
-You can also use the upgrade method if you keep the version number and just want to change some Helm values or other settings. But please be aware that changing some of settings might have some serious consequences if you already have volumes deployed! Not all Longhorn settings can be changed just by changing a number or a string. So you really want to consult the [Settings reference](https://longhorn.io/docs/1.6.1/references/settings/) to figure out what might happen if you change this or that setting or what you need to do before you apply a changed setting!
+You can also use the upgrade method if you keep the version number and just want to change some Helm values or other settings. But please be aware that changing some of settings might have some serious consequences if you already have volumes deployed! Not all Longhorn settings can be changed just by changing a number or a string. So you really want to consult the [Settings reference](https://longhorn.io/docs/1.6.3/references/settings/) to figure out what might happen if you change this or that setting or what you need to do before you apply a changed setting!
 
 That said to actually do the update/upgrade run
 
@@ -246,7 +246,7 @@ ansible-playbook \
   k8s.yml
 ```
 
-Longhorn has a [Deleting Confirmation Flag](https://longhorn.io/docs/1.6.1/references/settings/#deleting-confirmation-flag) which is set to `false` by default. In this case Longhorn refuses to be uninstalled. By setting `--extra-vars longhorn_delete=true` the Ansible role will set this flag to `true` and afterwards the Longhorn resources can be deleted by the role. Without `longhorn_delete` variable the role will refuse to finish uninstallation.
+Longhorn has a [Deleting Confirmation Flag](https://longhorn.io/docs/1.6.3/references/settings/#deleting-confirmation-flag) which is set to `false` by default. In this case Longhorn refuses to be uninstalled. By setting `--extra-vars longhorn_delete=true` the Ansible role will set this flag to `true` and afterwards the Longhorn resources can be deleted by the role. Without `longhorn_delete` variable the role will refuse to finish uninstallation.
 
 ## Setting/removing node labels
 

defaults/main.yml

@@ -3,7 +3,7 @@
 # SPDX-License-Identifier: GPL-3.0-or-later
 
 # Helm chart version
-longhorn_chart_version: "1.6.1"
+longhorn_chart_version: "1.6.3"
 
 # Helm release name
 longhorn_release_name: "longhorn"

molecule/default/converge.yml

@@ -2,6 +2,14 @@
 # Copyright (C) 2023 Robert Wimmer
 # SPDX-License-Identifier: GPL-3.0-or-later
 
+- name: Gather facts
+  hosts: all
+  become: true
+  gather_facts: true
+  tasks:
+    - name: Populate Ansible hostVars
+      ansible.builtin.setup:
+
 - name: Setup Longhorn
   hosts: all
   environment:

molecule/default/group_vars/all.yml

@@ -7,9 +7,9 @@ harden_linux_ntp: "systemd-timesyncd"
 
 # Password for user "root" and "vagrant" is "vagrant" in both cases. As
 # "vagrant" user is available in every Vagrant Ubuntu Box just use it.
-harden_linux_root_password: "$6$rounds=656000$mysecretsalt$fpyQ9hMON6iKKuM0Rz10WZKNJR4OkQTVfBmd4SPrJPsU9XmgQGRtogcUnFB5FLRIitswuQFr6Tr8Mos9l7Ojm0"
+harden_linux_root_password: "$6$ec6PmcEygP6do8Ls$847Pqqo1fXJFeMvPkmP3ipLQ9vhny1PYtwnnIptpZ1Sc8KXUuPGu29aUTOdNdgIfxR3Bix5SUkNfSMMCetej41"
 harden_linux_deploy_user: "vagrant"
-harden_linux_deploy_user_password: "$6$rounds=656000$mysecretsalt$fpyQ9hMON6iKKuM0Rz10WZKNJR4OkQTVfBmd4SPrJPsU9XmgQGRtogcUnFB5FLRIitswuQFr6Tr8Mos9l7Ojm0"
+harden_linux_deploy_user_password: "$6$ec6PmcEygP6do8Ls$847Pqqo1fXJFeMvPkmP3ipLQ9vhny1PYtwnnIptpZ1Sc8KXUuPGu29aUTOdNdgIfxR3Bix5SUkNfSMMCetej41"
 harden_linux_deploy_user_home: "/home/vagrant"
 harden_linux_deploy_user_uid: "1000"
 harden_linux_deploy_user_shell: "/bin/bash"
@@ -28,30 +28,6 @@ harden_linux_sshd_settings_user:
   "^PasswordAuthentication": "PasswordAuthentication yes"
   "^PermitRootLogin": "PermitRootLogin yes"
 
-# Open a few ports for ssh, Wireguard, HTTP, HTTPS and SMTP.
-harden_linux_ufw_rules:
-  - rule: "allow"
-    to_port: "22"
-    protocol: "tcp"
-  - rule: "allow"
-    to_port: "51820"
-    protocol: "udp"
-  - rule: "allow"
-    to_port: "80"
-    protocol: "tcp"
-  - rule: "allow"
-    to_port: "443"
-    protocol: "tcp"
-  - rule: "allow"
-    to_port: "25"
-    protocol: "tcp"
-
-# Allow all traffic from the following networks.
-harden_linux_ufw_allow_networks:
-  - "10.0.0.0/8"
-  - "172.16.0.0/12"
-  - "192.168.0.0/16"
-
 # Enable logging for UFW.
 harden_linux_ufw_logging: 'on'
 
@@ -68,6 +44,15 @@ harden_linux_sshguard_whitelist:
   - "172.16.0.0/12"
   - "192.168.0.0/16"
 
+# DNS
+harden_linux_systemd_resolved_settings:
+  - DNS=
+  - DNS=8.8.8.8 1.1.1.1 2606:4700:4700::1111 2620:fe::fe
+  - FallbackDNS=
+  - FallbackDNS=149.112.112.112 1.0.0.1 2620:fe::9 2606:4700:4700::1001
+  - DNSOverTLS=
+  - DNSOverTLS=opportunistic
+
 # Directory where the etcd certificates are stored on the Ansible controller
 # host. Certificate files for etcd will be copied from this directory to
 # the etcd nodes.
@@ -80,9 +65,14 @@ etcd_interface: "{{ k8s_interface }}"
 etcd_settings_user:
   "heartbeat-interval": "250"
   "election-timeout": "2500"
-
-# Generate certificates for Cilium to be able to connect to "etcd"
-# cluster to store its state.
+# Host names and IP addresses in the etcd certificates.
+etcd_cert_hosts:
+  - localhost
+  - 127.0.0.1
+# This list should contain all etcd clients that wants to connect to the etcd
+# cluster. The most important client is "kube-apiserver" of course. Also
+# "cilium" should connect. So we add this here too to generate the needed
+# certificates.
 etcd_additional_clients:
   - cilium
   - k8s-apiserver-etcd
@@ -142,9 +132,40 @@ k8s_encryption_config_key: "Y29uZmlndXJhdGlvbjIyCg=="
 k8s_apiserver_settings_user:
   "enable-aggregator-routing": "true"
 
+k8s_worker_kubelet_settings:
+  "config": "{{ k8s_worker_kubelet_conf_dir }}/kubelet-config.yaml"
+  "node-ip": "{{ hostvars[inventory_hostname]['ansible_' + k8s_interface].ipv4.address }}"
+  "kubeconfig": "{{ k8s_worker_kubelet_conf_dir }}/kubeconfig"
+  "seccomp-default": ""
+
 # Directory for the "runc" binaries
 runc_bin_directory: "/usr/local/sbin"
 
+# Directory to store the "containerd" archive after download
+containerd_tmp_directory: "/tmp"
+
+# Use "etcd" for Cilium
+cilium_etcd_enabled: "true"
+# Delegate Cilium tasks that needs to communicate with the Kubernetes API
+# server to the following host.
+cilium_delegate_to: "test-assets"
+# Template directory for custom "values.yml.j2"
+cilium_chart_values_directory: "templates"
+# Show debug output for Cilium Helm commands.
+cilium_helm_show_commands: true
+cilium_etcd_interface: "{{ k8s_interface }}"
+cilium_etcd_client_port: 2379
+cilium_etcd_nodes_group: "k8s_etcd"
+
+cilium_etcd_secrets_name: "cilium-etcd-secrets"
+cilium_etcd_cert_directory: "{{ k8s_ca_conf_directory }}"
+cilium_etcd_cafile: "ca-etcd.pem"
+cilium_etcd_certfile: "cert-cilium.pem"
+cilium_etcd_keyfile: "cert-cilium-key.pem"
+
+# Delegate tasks to create CoreDNS K8s resources to this host.
+coredns_delegate_to: "test-assets"
+
 # Common name for "etcd" certificate authority certificates.
 ca_etcd_csr_cn: "etcd"
 ca_etcd_csr_key_algo: "ecdsa"
@@ -193,10 +214,6 @@ k8s_controller_manager_sa_csr_key_size: "384"
 k8s_kube_proxy_csr_key_algo: "ecdsa"
 k8s_kube_proxy_csr_key_size: "384"
 
-# Cilium
-cilium_delegate_to: "test-assets"
-cilium_etcd_cert_directory: "{{ k8s_ca_conf_directory }}"
-
 # Longhorn settings
 longhorn_template_output_directory: "/tmp/longhorn"
 longhorn_delegate_to: "test-assets"

molecule/default/group_vars/k8s.yml

@@ -0,0 +1,10 @@
+---
+# Copyright (C) 2024 Robert Wimmer
+# SPDX-License-Identifier: GPL-3.0-or-later
+
+# Allow all traffic from the following networks.
+harden_linux_ufw_allow_networks:
+  - "10.32.0.0/16"     # Server Cluster IP range
+  - "10.200.0.0/16"    # Pod IP range
+  - "10.10.10.0/24"    # Wireguard IP range
+  - "172.16.10.0/24"   # VM IP range

molecule/default/group_vars/k8s_etcd.yml

@@ -0,0 +1,18 @@
+---
+# Copyright (C) 2024 Robert Wimmer
+# SPDX-License-Identifier: GPL-3.0-or-later
+
+# Open a few ports for ssh, Wireguard and etcd
+harden_linux_ufw_rules:
+  - rule: "allow"
+    to_port: "22"
+    protocol: "tcp"
+  - rule: "allow"
+    to_port: "51820"
+    protocol: "udp"
+  - rule: "allow"
+    to_port: "2379"
+    protocol: "tcp"
+  - rule: "allow"
+    to_port: "2380"
+    protocol: "tcp"

molecule/default/host_vars/test-assets.yml

@@ -2,6 +2,8 @@
 # Copyright (C) 2023 Robert Wimmer
 # SPDX-License-Identifier: GPL-3.0-or-later
 
+ansible_python_interpreter: "/usr/bin/python3"
+
 wireguard_address: "10.10.10.5/24"
 wireguard_port: 51820
 wireguard_persistent_keepalive: "30"

molecule/default/host_vars/test-controller1.yml

@@ -6,3 +6,12 @@ wireguard_address: "10.10.10.10/24"
 wireguard_port: 51820
 wireguard_persistent_keepalive: "30"
 wireguard_endpoint: "172.16.10.10"
+
+ha_proxy_frontend_bind_address: "127.0.0.1"
+ha_proxy_frontend_port: "16443"
+
+k8s_ctl_api_endpoint_host: "127.0.0.1"
+k8s_ctl_api_endpoint_port: "16443"
+
+k8s_worker_api_endpoint_host: "{{ k8s_ctl_api_endpoint_host }}"
+k8s_worker_api_endpoint_port: "{{ k8s_ctl_api_endpoint_port }}"