digitalocean k3s series cleanup

content/resources/infra-ops/kubernetes-ansible-digital-ocean-k3s-1.md

@@ -44,7 +44,7 @@ Additionally, install [`yamllint`](https://yamllint.readthedocs.io/en/stable/) t
 For `pip` users, `requirements.txt`:
 
 ```text
-ansible==9.*
+ansible==10.*
 yamllint=1.*
 ```
 
@@ -56,10 +56,11 @@ authors = ["francoposa <[email protected]>"]
 description = ""
 name = "learn-infra-ops"
 version = "0.1.0a0"
+package-mode = false
 
 [tool.poetry.dependencies]
-python = "^3.10"
-ansible = "9.*"
+python = "^3.12"
+ansible = "10.*"
 
 [tool.poetry.dev-dependencies]
 yamllint = "1.*"
@@ -99,7 +100,7 @@ To upgrade the collection to the latest version:
 To install a particular version of the collection:
 
 ```shell
-% ansible-galaxy collection install community.digitalocean:==1.15.0
+% ansible-galaxy collection install community.digitalocean:==1.27.0
 ```
 
 ## 1. Create a DigitalOcean Server with Ansible
@@ -126,15 +127,15 @@ By default, the Ansible module waits for the server to be fully active before re
     - name: create k3s master node droplet in project "demo"
       community.digitalocean.digital_ocean_droplet:
         state: active
-        name: debian-s-1vcpu-2gb-sfo3-01
+        name: debian-s-2vcpu-2gb-sfo3-01
         unique_name: true
         project: demo
         tags:
           - demo
           - k3s-demo
           - k3s-demo-master
         image: debian-12-x64
-        size: s-1vcpu-2gb
+        size: s-2vcpu-2gb
         region: sfo3
         ssh_keys:
           # md5 fingerprint for our ed25519 ssh key
@@ -177,9 +178,9 @@ Current slugs are also available directly from the DigitalOcean CLI:
 
 ### 1.1 Cloud Init and User Data
 [Cloud Init](https://cloudinit.readthedocs.io/en/latest/index.html) is a standardized approach to configuring cloud compute instances.
-On first boot, the configuration can set up user accounts, apply networking rules, install packages and much more.
+On first boot, the configuration can set up user accounts, apply networking rules, install packages, and much more.
 
-To keep things simple and familiar, we only utilize [user data script format](https://cloudinit.readthedocs.io/en/latest/explanation/format.html#user-data-script),
+To keep things simple and familiar, we will only utilize the [user data script format](https://cloudinit.readthedocs.io/en/latest/explanation/format.html#user-data-script) here,
 which allows Cloud Init to run arbitrary shell scripts during the server initialization.
 Sticking to the shell script format allows us to run and test locally if needed without knowing anything else about Cloud Init.
 

content/resources/infra-ops/kubernetes-ansible-digital-ocean-k3s-2.md

@@ -72,12 +72,12 @@ While we will ultimately move on to using dynamic inventory, we can first take a
 #### Declaring Static Host Groups
 
 When we created our server with the DigitalOcean Ansible module in [Part 1](/resources/infra-ops/zero-to-production-with-kubernetes-1/), we assigned three tags with the intention of using them later as the Ansible host groups.
-Our single host is in all three groups we created: `k3s-demo-master` for the master node, `k3s demo`, used for all nodes in the cluster, and `demo` for all resources in the "demo" project of the DigitalOcean account.
+Our single host is in all three groups we created: `k3s-demo-master` for the master node, `k3s demo` for all nodes in the cluster, and `demo` for all resources in the "demo" project of the DigitalOcean account.
 
 #### Assigning Static Host Variables
 
-* `ansible_host` - the public IPv4 address assigned to the server on creation from DigitalOcean's public IP space.
-* `ansible_user` - the `USERNAME` from the [Cloud Init script from Part 1](/resources/infra-ops/zero-to-production-with-kubernetes-1/#cloud-init-and-user-data).
+* `ansible_host` - set this to the public IPv4 address assigned to the server on creation.
+* `ansible_user` - set this to the `USERNAME` from the [Cloud Init script from Part 1](/resources/infra-ops/zero-to-production-with-kubernetes-1/#cloud-init-and-user-data).
   * use DigitalOcean's default `root` user if you skipped the user setup via cloud-init step
 
 #### DigitalOcean Static Inventory
@@ -196,6 +196,7 @@ This will prevent us from having to re-declare the `ansible_user` or any other c
 We can add the following to `[inventory directory]/group_vars/all.yaml`, or `demo.yaml`, or whichever host group we want to target.
 
 ```yaml
+# github.com/francoposa/learn-infra-ops/blob/main/infrastructure/ansible/inventory/sources/group_vars/demo.yaml
 ---
 ansible_user: infra_ops
 ```

content/resources/infra-ops/kubernetes-ansible-digital-ocean-k3s-3.md

@@ -83,8 +83,6 @@ bind-address: "x.x.x.x"
 ## 2. Copy K3s Config to Server and Install K3s with Ansible
 
 ```shell
-% export DO_API_TOKEN=dop_v1_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-
 % ansible-playbook \
   --inventory ./infrastructure/ansible/inventory/sources \
   ./infrastructure/ansible/k3s/install.yaml
@@ -154,7 +152,14 @@ If this is not preferred, we have multiple viable options:
 * change the order of kubeconfigs on merge to retain the desired config
 * skip merging kubeconfigs altogether and switch between configs with the `KUBECONFIG` environment variable
 
-As I am usually spinning up a fresh cluster after tearing down the last one, I use this playbook as-is, allowing the new `default` kubeconfig context to overwrite the old.
+As I am usually spinning up a fresh cluster after tearing down the last one,
+I use this playbook as-is, allowing the new `default` kubeconfig context to overwrite the old.
+
+```shell
+% ansible-playbook \
+  --inventory ./infrastructure/ansible/inventory/sources \
+  ./infrastructure/ansible/k3s/local-kube-config.yaml
+```
 
 ```yaml
 # github.com/francoposa/learn-infra-ops/blob/main/infrastructure/ansible/k3s/local-kube-config.yaml
@@ -211,6 +216,6 @@ Kubernetes control plane is running at https://137.184.2.102:6443
 We now have a fully-functioning single-node K3s Kubernetes cluster running and available in a cloud server.
 The public IP address assigned to the VM allows us to manage our server and kubernetes cluster from anywhere.
 
-Moreover, all of our configuration and installation steps are declared in version-controlled files,
+All of our configuration and installation steps are declared in version-controlled files,
 enabling us to duplicate the same infrastructure state across as many hosts as we want,
 or repeat the same infrastructure state in a single host after tearing it down and spinning it back up.