Update notes on the cloud computing course and Nix

Was able to finally pass through the ArgoCD installation among other
things. I also updated more exercises to tangle my solutions into a file.

structured/assets/challenges.suse-cloud-native-fundamentals-scholarship-program/kubernetes-resources.sh

@@ -0,0 +1,14 @@
+#!/usr/bin/env bash
+# Create the namespace with the specified label.
+kubectl create namespaces demo
+kubectl label namespaces demo tier=test
+
+# Create the specified deployment.
+kubectl create deployment nginx-alpine --image=nginx:alpine --replicas=3 --namespace=demo
+kubectl label deployment nginx-alpine app=nginx tag=alpine --namespace=demo
+
+# Expose the deployment as a service.
+kubectl expose deployment nginx-alpine --namespace=demo --port=8111
+
+# Create the config map.
+kubectl create configmaps nginx-version --namespace=demo --from-literal=version=alpine

structured/assets/challenges.suse-cloud-native-fundamentals-scholarship-program/manifests/configmap.yaml

@@ -0,0 +1,8 @@
+apiVersion: v1
+data:
+  version: alpine
+kind: ConfigMap
+metadata:
+  creationTimestamp: null
+  name: nginx-version
+  namespace: demo

structured/assets/challenges.suse-cloud-native-fundamentals-scholarship-program/manifests/deployment.yaml

@@ -0,0 +1,26 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  creationTimestamp: null
+  labels:
+    app: nginx
+    tag: alpine
+  name: nginx-alpine
+  namespace: demo
+spec:
+  replicas: 3
+  selector:
+    matchLabels:
+      app: nginx-alpine
+  strategy: {}
+  template:
+    metadata:
+      creationTimestamp: null
+      labels:
+        app: nginx-alpine
+    spec:
+      containers:
+      - image: nginx:alpine
+        name: nginx
+        resources: {}
+status: {}

structured/assets/challenges.suse-cloud-native-fundamentals-scholarship-program/manifests/namespace.yaml

@@ -0,0 +1,9 @@
+apiVersion: v1
+kind: Namespace
+metadata:
+  creationTimestamp: null
+  name: demo
+  labels:
+    tier: test
+spec: {}
+status: {}

structured/assets/challenges.suse-cloud-native-fundamentals-scholarship-program/manifests/service.yaml

@@ -0,0 +1,18 @@
+apiVersion: v1
+kind: Service
+metadata:
+  creationTimestamp: null
+  labels:
+    app: nginx
+    tag: alpine
+  name: nginx-alpine
+  namespace: demo
+spec:
+  ports:
+  - port: 8111
+    protocol: TCP
+    targetPort: 8111
+  selector:
+    app: nginx-alpine
+status:
+  loadBalancer: {}

structured/challenges.suse-cloud-native-fundamentals-scholarship-program.org

@@ -3,7 +3,7 @@
 :END:
 #+title: Solutions to SUSE Cloud native fundamentals scholarship exercises
 #+date: "2021-06-08 23:23:35 +08:00"
-#+date_modified: "2021-06-21 10:54:53 +08:00"
+#+date_modified: "2021-07-02 16:48:37 +08:00"
 #+language: en
 
 
@@ -366,7 +366,7 @@ Now you have learned many Kubernetes recourses, in this exercise, you will deplo
 
 This is practical test but it can summarized with a shell script.
 
-#+begin_src bash  :eval no
+#+begin_src bash  :eval no  :tangle (my/concat-assets-folder "kubernetes-resources.sh")  :shebang "#!/usr/bin/env bash"
 # Create the namespace with the specified label.
 kubectl create namespaces demo
 kubectl label namespaces demo tier=test
@@ -419,7 +419,7 @@ The following manifests are created with the option to print the resources in YA
 Here's one for the namespace.
 The command used to make the template is ~kubectl create namespace demo --dry-run=client --output=yaml~.
 
-#+begin_src yaml
+#+begin_src yaml  :tangle (my/concat-assets-folder "manifests/namespace.yaml")
 apiVersion: v1
 kind: Namespace
 metadata:
@@ -434,7 +434,7 @@ status: {}
 The manifest for the deployment.
 The command used to create the starting template is ~kubectl create deployment nginx-alpine --namespace=demo --replicas=3 --image=nginx:alpine --dry-run=client --output=yaml~.
 
-#+begin_src yaml
+#+begin_src yaml  :tangle (my/concat-assets-folder "manifests/deployment.yaml")
 apiVersion: apps/v1
 kind: Deployment
 metadata:
@@ -466,7 +466,7 @@ status: {}
 The service manifest should be created after the deployment manifest is applied (i.e., ~kubectl apply -f deployment.yaml~).
 It is created with ~kubectl expose deploy nginx-alpine --port=8111 --dry-run=client --output=yaml --namespace=demo~.
 
-#+begin_src yaml
+#+begin_src yaml  :tangle (my/concat-assets-folder "manifests/service.yaml")
 apiVersion: v1
 kind: Service
 metadata:
@@ -490,7 +490,7 @@ status:
 The resulting YAML output is from running the command (i.e., ~kubectl create configmap nginx-version --from-literal=version=alpine --dry-run=client --output=yaml --namespace=demo~).
 No cleaning up is required.
 
-#+begin_src yaml
+#+begin_src yaml  :tangle (my/concat-assets-folder "manifests/configmap.yaml")
 apiVersion: v1
 data:
   version: alpine
@@ -566,3 +566,55 @@ jobs:
 This is shamelessly ripped off from the sample from the [[https://github.com/marketplace/actions/build-and-push-docker-images][GitHub Actions page]].
 I realized it's basically the answer for this exercise.
 Embarrassing that I spent an hour for this.
+
+
+
+
+* The CD fundamentals
+
+Continuous Delivery (CD) is the ability to get code changes reliably to production environments.
+This practice should be automated and should enable developers to provide value to consumers efficiently.
+
+In this exercise, you will use ArgoCD to automate the delivery of an application to a Kubernetes cluster.
+
+
+** Solution
+
+The manifest is really the same as the example manifest from the walkthrough except with a different path pointing to the required manifests.
+
+#+begin_src yaml  :tangle (my/concat-assets-folder "argocd-nginx-alpine.yaml")
+apiVersion: argoproj.io/v1alpha1
+kind: Application
+metadata:
+  name: ngnix-alpine
+  namespace: argocd
+spec:
+  destination:
+    namespace: default
+    server: https://kubernetes.default.svc
+  project: default
+  source:
+    path: exercises/manifests
+    repoURL: https://github.com/udacity/nd064_course_1
+    targetRevision: HEAD
+  syncPolicy: {}
+#+end_src
+
+Then integrate it into the cluster with the following command.
+
+#+begin_src shell  :eval no
+kubectl apply -f argocd-nginx-alpine.yaml
+#+end_src
+
+You should then see the project on the ArgoCD application list where it requires an initial sync.
+
+For assurance, you can check to see if the resources are deployed.
+Continuing from [[Declarative Kubernetes manifests]], the resources are mostly in the =demo= namespace.
+
+#+begin_src shell  :eval no
+kubectl get pod -n demo
+kubectl get deploy -n demo
+kubectl get rs -n demo
+#+end_src
+
+You should see them up and running.

structured/cookbook.bash.percent-encoding.org

@@ -3,7 +3,7 @@
 :END:
 #+title: Percent encoding in Bash
 #+date: "2021-06-23 21:10:33 +08:00"
-#+date_modified: "2021-06-24 20:42:43 +08:00"
+#+date_modified: "2021-07-01 13:46:04 +08:00"
 #+language: en
 
 
@@ -50,7 +50,10 @@ To decode percent-encoded strings:
 function urldecode {
     # urldecode <string>
 
+    # Replace all pluses with spaces since it usually represents it in URLs.
     local url_encoded="${1//+/ }"
+
+    # Replace all percent sign with '\x' and print the message with byte interpretation.
     printf '%b\n' "${url_encoded//%/\\x}"
 }
 

structured/linux.systemd.org

@@ -1,6 +1,6 @@
 #+title: Exploring systemd features
 #+date: "2021-05-20 22:37:22 +08:00"
-#+date_modified: "2021-06-19 15:07:52 +08:00"
+#+date_modified: "2021-07-01 11:54:34 +08:00"
 #+language: en
 #+property: header-args  :eval no
 
@@ -69,6 +69,52 @@ But you can omit it if you named the timer unit file similarly (e.g., =borg-back
 You can find more information about it from the =systemd.time.5= manual page.
 Furthermore, systemd has a testing tool for time with ~systemd-analyze {timespan,timestamp,calendar}~.
 
+#+begin_src shell  :eval yes
+printf "Timespan example:\n"
+printf "..............\n"
+systemd-analyze timespan 4000min
+printf "..............\n\n"
+
+printf "Timestamp example:\n"
+printf "..............\n"
+systemd-analyze timestamp 2021-07-01
+printf "..............\n\n"
+
+printf "Calendar example:\n"
+printf "..............\n"
+systemd-analyze calendar "*-1/4-5 0/2:00:00"
+printf "..............\n\n"
+#+end_src
+
+#+results:
+#+begin_example
+Timespan example:
+..............
+Original: 4000min
+      μs: 240000000000
+   Human: 2d 18h 40min
+..............
+
+Timestamp example:
+..............
+  Original form: 2021-07-01
+Normalized form: Thu 2021-07-01 00:00:00 PST
+       (in UTC): Wed 2021-06-30 16:00:00 UTC
+   UNIX seconds: @1625068800
+       From now: 11h ago
+..............
+
+Calendar example:
+..............
+  Original form: *-1/4-5 0/2:00:00
+Normalized form: *-01/4-05 00/2:00:00
+    Next elapse: Sun 2021-09-05 00:00:00 PST
+       (in UTC): Sat 2021-09-04 16:00:00 UTC
+       From now: 2 months 4 days left
+..............
+
+#+end_example
+
 
 
 
@@ -152,23 +198,56 @@ Like most of the components, it can be used at user-level with their set locatio
 
 Just plop down a service unit file at one of the search paths and you can start managing right away.
 For more information, see the manual page (i.e., =systemd.service.5=).
+A summarized version can be found at [[Service configuration]].
 
-Here's an example of a user service resided as =$HOME/.config/systemd/user/borgbackup@.service=.
+Here's an example of a user service resided as =$HOME/.config/systemd/user/drive-backup.service=.
 
 #+begin_src ini
 [Unit]
-Description=Periodic safety backup for %i
+Description=Periodic safety backup for my external drive
 Documentation=man:borg(1) https://www.borgbackup.org/ https://torsion.org/borgmatic/
 
 [Service]
-Type=simple
-ExecStartPre=%h/.nix-profile/bin/borgmatic --config %h/dotfiles/borgmatic/%i.yaml --verbosity 2 create
-ExecStart=%h/.nix-profile/bin/borgmatic --config %h/dotfiles/borgmatic/%i.yaml --verbosity 2 check
+Type=oneshot
+ExecStart=%h/.nix-profile/bin/borgmatic --config %h/dotfiles/borgmatic/personal-drive.yaml --verbosity 2 create
+ExecStart=%h/.nix-profile/bin/borgmatic --config %h/dotfiles/borgmatic/personal-drive.yaml --verbosity 2 prune
+ExecStart=%h/.nix-profile/bin/borgmatic --config %h/dotfiles/borgmatic/personal-drive.yaml --verbosity 2 check
 
 [Install]
 WantedBy=default.target
 #+end_src
 
+You can then start the service with:
+
+#+begin_src shell  :eval no
+systemctl --user start drive-backup.service
+#+end_src
+
+You can also stop it with the =stop= subcommand (e.g., ~systemctl --user stop drive-backup.service~) and restart it with =restart= (e.g., ~systemctl --user restart drive-backup.service~).
+
+If you want to enable it at startup, you can go with =enable= subcommand.
+(To disable it, use the =disable= subcommand.)
+
+#+begin_src shell  :eval no
+systemctl --user enable drive-backup.service
+#+end_src
+
+systemd will use the configuration file as-is by the time it is started/enabled.
+Which means if the config file has been modified after activation, it will not take effect until you restarted it.
+For this, you can reload the daemon with =daemon-reload= subcommand.
+But for simpler cases, you can use the =reload= subcommand without fully restarting the daemon.
+
+#+begin_src shell  :eval no
+systemctl --user reload drive-backup.service
+
+# You could also use...
+#   systemctl --user daemon-reload
+# ...if you need a stronger option.
+#+end_src
+
+
+** Service configuration
+
 There are different types of services.
 
 - The most common type of service is =simple= which considers the unit active after the main process is forked (e.g., =Service.ExecStart=).

structured/literature.suse-cloud-native-fundamentals-scholarship-program.org

@@ -3,7 +3,7 @@
 :END:
 #+title: SUSE Cloud native fundamentals scholarship program
 #+date: "2021-06-07 18:21:19 +08:00"
-#+date_modified: "2021-06-19 17:31:22 +08:00"
+#+date_modified: "2021-07-02 18:58:12 +08:00"
 #+language: en
 
 
@@ -146,3 +146,14 @@ Best practices for application deployment:
   + GitHub Actions enables event-listening jobs
   + each job are then divided into steps
   + you can configure GitHub Actions through =.github/workflows= inside of the GitHub repo
+
+- in this chapter, they go with ArgoCD which is an application deployment frontend to Kubernetes clusters
+
+- with similar configurations, you may want to use templates;
+  this is where configuration managers come in;
+  this course chooses Helm as the tool of the trade as it is integrated into ArgoCD
+
+- Helm is a configuration manager
+  + it mainly manages charts which are basically packages in a package manager
+  + a chart contains parameterized values which is mainly done through Go templates
+  + Helm recognizes a chart with the =Chart.yaml= file that contains metadata about the deployment

structured/tools.nix.org

@@ -3,7 +3,7 @@
 :END:
 #+title: The basics of Nix package manager
 #+date: "2021-06-05 12:34:49 +08:00"
-#+date_modified: "2021-06-30 22:36:30 +08:00"
+#+date_modified: "2021-06-30 23:01:51 +08:00"
 #+language: en
 
 
@@ -16,12 +16,12 @@ Taking it up to the next level with NixOS, your whole installation.
 
 * Ecosystem
 
-Nix has tools to make setting up environments easier.
+Nix has several tools that integrates them into the already existing ecosystem of developer tools.
 
-- [[https://direnv.net/][direnv]] has [[https://github.com/direnv/direnv/wiki/Nix][integration with Nix]] as well as a lot of editors
-- [[https://github.com/nix-community/lorri][lorri]] replaces nix-shell integrating with direnv
-- [[https://github.com/nmattia/niv][niv]] provides a easier way to manage dependencies though it will be easier with Nix flakes
-- [[Nix flakes]] is an upcoming feature for Nix, replacing the traditional Nix channels into a decentralized set of derivations that can be retrieved from anywhere similar to Go modules [fn:: At a glance, anyways. I'm not experienced enough with Go to say that with utmost confidence.]
+- [[https://direnv.net/][direnv]] has [[https://github.com/direnv/direnv/wiki/Nix][integration with Nix]] as well as a lot of editors.
+- [[https://github.com/nix-community/lorri][lorri]] replaces nix-shell integrating with direnv.
+- [[https://github.com/nmattia/niv][niv]] provides a easier way to manage dependencies though it will be easier with Nix flakes.
+- [[Nix flakes]] is an upcoming feature for Nix, replacing the traditional Nix channels into a decentralized set of derivations that can be retrieved from anywhere similar to Go modules [fn:: At a glance, anyways. I'm not experienced enough with Go to say that with utmost confidence.].
 - [[https://cachix.org/][Cachix]] is a cache service enabling to easily distribute binaries built with Nix.
 
 
@@ -86,7 +86,6 @@ let overlay = self: super:
       }
 #+end_src
 
-# TODO: Bring more examples
 For another example, you can see some examples from [[https://github.com/neovim/neovim/blob/f695457f815544d0dc16469569c70556e3165bb6/contrib/flake.nix][Neovim]] and [[https://gitlab.com/veloren/veloren/-/tree/685f4971ac0deb31b301e9d2bc0201d2531fd895/nix][Veloren]] (which also uses Nix flakes).
 
 You can set overlays automatically either by setting =nixpkgs.overlays= from your system configuration or =~/.config/nixpkgs/overlays/= folder for user-specific settings.
@@ -150,7 +149,46 @@ github:edolstra/dwarffs/f691e2c991e75edb22836f1dbe632c40324215c5
 
 Let's build from one of the outputs of call_flake-sample-object().
 
-#+begin_src shell  :shebang "#!/usr/bin/env nix-shell"  :results silent  :exports none
+#+begin_src shell  :shebang "#!/usr/bin/env nix-shell"
 #! nix-shell -i bash -p nixUnstable
-nix --experimental-features 'nix-command flakes' build '<<flake-sample-object()>>#checks.aarch64-linux.build'
+nix --experimental-features 'nix-command flakes' build 'github:edolstra/dwarffs#checks.aarch64-linux.build'
+
+nix --experimental-features 'nix-command flakes' shell 'github:edolstra/dwarffs' --command dwarffs --version
 #+end_src
+
+#+results:
+: fusermount version: 2.9.9
+
+For full reproducibility, you can refer to specific point of a flake (e.g., commit).
+
+#+begin_tip
+To easily get a pinned URL, you can run =flake metadata= subcommand.
+
+#+begin_src shell  :shebang "#!/usr/bin/env nix-shell"
+#! nix-shell -i bash -p nixUnstable
+nix --experimental-features 'nix-command flakes' flake metadata 'github:edolstra/dwarffs' | sed -e "s/\x1b\[.\{1,5\}m//g"
+#+end_src
+
+#+results:
+#+begin_example
+Resolved URL:  github:edolstra/dwarffs
+Locked URL:    github:edolstra/dwarffs/f691e2c991e75edb22836f1dbe632c40324215c5
+Description:   A filesystem that fetches DWARF debug info from the Internet on demand
+Path:          /nix/store/769s05vjydmc2lcf6b02az28wsa9ixh1-source
+Revision:      f691e2c991e75edb22836f1dbe632c40324215c5
+Last modified: 2021-01-21 22:41:26
+Inputs:
+├───nix: github:NixOS/nix/6254b1f5d298ff73127d7b0f0da48f142bdc753c
+│   ├───lowdown-src: github:kristapsdz/lowdown/1705b4a26fbf065d9574dce47a94e8c7c79e052f
+│   └───nixpkgs: github:NixOS/nixpkgs/ad0d20345219790533ebe06571f82ed6b034db31
+└───nixpkgs follows input 'nix/nixpkgs'
+#+end_example
+#+end_tip
+
+#+begin_src shell  :shebang "#!/usr/bin/env nix-shell"
+#! nix-shell -i bash -p nixUnstable
+nix --experimental-features 'nix-command flakes' shell github:edolstra/dwarffs/f691e2c991e75edb22836f1dbe632c40324215c5 --command dwarffs --version
+#+end_src
+
+#+results:
+: fusermount version: 2.9.9