Post-dry-run enhancements for Linux workshop (#2)

Co-authored-by: Justin DeBo <justin.debo@gmail.com>

Author: ryapric

linux/Makefile

@@ -4,10 +4,26 @@ up-local:
 	@vagrant up db
 	@vagrant up $(local_team_servers)
 
+up-aws:
+	@(cd ./terraform && terraform apply)
+
+yeet-aws:
+	@(cd ./terraform && terraform apply -auto-approve)
+	@make -s provision-aws
+
 provision-local:
 # Don't re-provision DB at the same time, since it throws off team server tests
 	@vagrant provision db
 	@vagrant provision $(local_team_servers)
 
+provision-aws:
+	@(cd ./terraform && bash ../scripts/provision-ec2.sh)
+
 down-local:
 	@vagrant destroy -f
+
+down-aws:
+	@(cd ./terraform && terraform destroy)
+
+nuke-aws:
+	@(cd ./terraform && terraform destroy -auto-approve)

linux/Vagrantfile

@@ -1,7 +1,7 @@
 Vagrant.configure("2") do |config|
-  box = "debian/bullseye64"
+  box = "debian/bookworm64" # Debian 12
 
-  cpus   = 2
+  cpus   = 1
   memory = 768
 
   config.vm.provider "virtualbox" do |vb|
@@ -27,13 +27,21 @@ Vagrant.configure("2") do |config|
 
     db.vm.network "private_network", ip: db_addr
     db.vm.network "forwarded_port", guest: 5432, host: 5432, protocol: "tcp"
+    db.vm.network "forwarded_port", guest: 8080, host: 8080, protocol: "tcp"
 
     db.vm.synced_folder ".", "/vagrant", disabled: true
 
     db.vm.provision "file", source: "./scripts", destination: "/tmp/scripts"
+    db.vm.provision "file", source: "./score-server", destination: "/tmp/score-server"
 
     db.vm.provision "shell",
       inline: <<-SCRIPT
+        # Need both running here for Vagrant -- other platforms should ONLY have 2332
+        sudo sh -c 'grep 2332 /etc/ssh/sshd_config || printf "Port 2332\nPort 22\n" >> /etc/ssh/sshd_config'
+        sudo systemctl restart ssh
+
+        rm -rf /root/score-server
+        sudo cp -r /tmp/score-server /root/score-server
         bash /tmp/scripts/init-db.sh
       SCRIPT
   end
@@ -55,6 +63,10 @@ Vagrant.configure("2") do |config|
 
       team.vm.provision "shell",
         inline: <<-SCRIPT
+          # Need both running here for Vagrant -- other platforms should ONLY have 2332
+          sudo sh -c 'grep 2332 /etc/ssh/sshd_config || printf "Port 2332\nPort 22\n" >> /etc/ssh/sshd_config'
+          sudo systemctl restart ssh
+
           export team_name="Team-#{i}"
           export db_addr='#{db_addr}'
           bash /tmp/scripts/init.sh

linux/dummy-app-src/.gitignore

@@ -1 +1,6 @@
+# the possible locations of the app binary itself, and its debfile
 app
+*.deb
+dist/debian/app/usr/bin/app
+# but NOT its Debian packaging root directory, which must have the same name
+!dist/debian/app/

linux/dummy-app-src/dist/debian/app/DEBIAN/control

@@ -0,0 +1,5 @@
+Package: app
+Version: 1.0.0
+Architecture: amd64
+Maintainer: Ricky Bobby <bigredluvr@talladega.net>
+Description: Literally prints money for our company

linux/dummy-app-src/dist/debian/app/usr/bin/.env

@@ -0,0 +1,2 @@
+# This file doesn't actually do anything, but there needs to be a file in the
+# tree so that git commits the directory structure itself

linux/dummy-app-src/go.mod

@@ -1,3 +1,3 @@
 module example.com/myteam/app
 
-go 1.15
+go 1.19

linux/instructions/congrats.md

@@ -0,0 +1,10 @@
+Congratulations!
+================
+
+You got the app working again, and your company is once again printing money
+hand over fist. Your boss is going to be thrilled! Remember to ask for a raise
+during your next performance review `;-)`
+
+There's nothing else for you to do here except celebrate your accomplishments!
+Now you can kick back, relax... orrr, if you're feeling adventurous, try to
+break the workshop scoring system in your favor.

linux/instructions/step_0.md

@@ -3,7 +3,7 @@ Oh no! Our app isn't running!
 
 Your company runs a handful of web applications on their Linux servers.
 Unfortunately, it seems that at least one of them has stopped responding to
-healthcheck pings. This is *bad* -- ever second that service isn't running, the
+healthcheck pings. This is *bad* -- every second that service isn't running, the
 company isn't making any money! Well, at least that's how your boss feels. You
 just work here.
 

linux/instructions/step_1.md

@@ -1,8 +1,9 @@
 Step 1: Rebuild the app binary
 ==============================
 
-You land on the server and need to figure out why the application isn't running.
-Based on the architecture diagram for the app, you know the source code for it
+You hop into the production server and need to figure out why the application isn't 
+running. Based on the architecture diagram for the app and your knowledge of your 
+company's deployment pipelines, you know the source code for it
 should have been dumped into the directory `/opt/app`. That's probably the best
 place to start looking; as a first step, see if you can get the app binary
 built. Note that the application is written in Go, so you might need to look up

linux/instructions/step_3.md

@@ -11,5 +11,9 @@ managed by a tool called `systemd`, defined in what are called "unit files".
 Furthermore, you know that your app's service definition is supposed to be
 (aptly) named `app.service`.
 
-See if that service exists on the machine. If not, create it, and get it
-running.
+Create that service, and get it running. You need to make sure it runs *even if
+the system reboots* -- meaning that if the server is restarted for any reason,
+the app service needs to start again *without you starting it manually*.
+
+If for any reason you need to check out more detailed logs of the service, you
+can also use the separate `journald` command to inspect them.