We have added markdown linting to the bootcamp and a github action. The CI action does not block any merges or pushes as there are still violations we need to make a choice on.

The action on this ticket is to

• Review violations and make executive choice on if we should fix or ignore the rule
• Build out rule file
• Fix or exclude all rule violations
• change github action to block on error

Apprentices said they had issues with the exercise. Most of the issues seemed to getting spring petclinic running in centOS 7. we should be using CentOS 9 since 7 is EOL. And getting the official spring petclinic running on centOS 9 was straight forward. This seems like a good update as it removes tech debt and allows campers to focus on the exercise lesson of spinning up EC2 instances with userdata

• Fix Formatting
• Remove alternative step to create DB through Lambda
• Clarify Step for s3 event creation
• Add deliverables
• Benefits and Use Cases of Lambdas

Adding initial Github sections to the bootcamp involving Actions, Projects, API's, and maybe a little bit about Security. Goal is to create an iterative project where you end up with a pretty flushed out Org, repos, workflows etc to reference later. Should be easy to add on to.

https://devops-bootcamp.liatr.io/#/3-cloud-computing/3.2.3-auto-scaling

Amazon is deprecating 'launch configurations' for Amazon EC2 Auto Scaling and is migrating to 'Launch Templates'. We need to update 3.2.3 to use Launch Templates

Migrate to Launch Templates

Depends on #302

Learning Goal

Docker Compose

This one looks pretty straight forward but depends on 2.4. Just update it to mention GitHub runner. This section is also missing Deliverables so that would be a welcome add

Learning Goal

Introduction to EC2

The exercise in this section is to spin up two EC2 instances make one a Jenkins server and the other a Jenkins agent. Then run some builds on the hosts. Really Jenkins just servers as a 'thing to install' that also communicates with another host. We can do lots of things here.

I am not really opposed to keeping this section as Jenkins. Since it is still a relevant CI/CD tool that some of our clients use. If we keep this as Jenkins given we are stripping much of the other Jenkins sections out we should update this section to have more general information about Jenkins and point apprentices to docs so for creating a pipeline.

If we want to remove Jenkins here are a few ideas for alternatives I think would be beneficial:

Grafana -- one node as a Grafana server the other node running a data collection agent like telegraf https://grafana.com/tutorials/stream-metrics-from-telegraf-to-grafana

Ansible -- one node as an Ansible server the other as a node with the Ansible agent. Then apply a simple playbook that installs put a hello world text file on the node with the agent.

Zabbix server -- setup basic monitor on other node

• Deliverables could use some love here

The Problem

Chapter 2 of the bootcamp is centered around Virtualization. The chapter tells the following 'story' with its exercises. The camper is introduced to virtualization via a GUI and VirtualBox. Then they are introduced to Packer leveraging VirtualBox plugins to build custom vbox images. Then they are shown Vagrant and leverage their Packer script to create custom vbox machines with Vagrant.

As a company we have moved to Apple Silicon which is an ARM processor. VirtualBox is an x86 hypervisor and while there is a developer build that runs on m1/m2 chips this build essentially converts ARM commands to x86 commands and does so poorly. The result is this build does not work for any modern nix system. Threads suggest this will never really become a production ready thing and so alternatives are needed.

Options

The options for ARM virtualization is limited. Especially if we are looking for free solutions. There seems to be well supported paid solutions in VMWare and Parallels that integrate (seemingly) well with both Packer and Vagrant so either of these appear to be near 1-to-1 substitutions with VirtualBox bound exercises. As for free options there really is only QEMU.

QEMU

QEMU is a generic machine emulator with support for a wide array of architectures, aarch64 included. At a glance it seems like a good fit as there is the UTM project for a simple GUI experience, there is a Packer QEMU Builder, and a Vagrant QEMU Provider. But the devil is in the details.

UTM

This seems to work well enough for the exercises. It is already in the bootcamp and works with CentOS 9 images. I did have issues booting CentOS 7 images but if we have one (and the preferred most recent version of redhat we are probably OK)

QEMU Packer Builder

This builder targets KVM. This really is the 'normal' way that QEMU does virtualization. As previously stated QEMU is an emulator. Actually virtualization happens with KVM. KVM is and x86 project and not available on apple silicon. So without it QEMU has to emulate using accelerators and JIT translations. The packer builder is not really made for aarch64 versions of QEMU. And while it can can be modified I was unable to get it to work. Below are some of the stand out changes that had to be made and were I got blocked

source "qemu" "centos9" {
  iso_url = "https://mirror.stream.centos.org/9-stream/BaseOS/aarch64/iso/CentOS-Stream-9-20230508.0-aarch64-dvd1.iso"
  iso_checksum = "766b79db253487ad0ccebcc6dd4f72848357e10cffe03adc6a03a70d6bdbe6c7"
  disk_size = 10240
  headless = true
  use_default_display=true
  qemu_binary = "/opt/homebrew/bin/qemu-system-aarch64"
  machine_type = "virt"
  memory = 4096
  format = "qcow2"
  http_directory = "http"
  http_port_min = 8000
  http_port_max = 9000
  boot_wait = "2s"
  boot_command = ["<tab> text ks=http://{{ .HTTPIP }}:{{ .HTTPPort }}/anaconda-ks.cfg<enter><wait>"]
  ssh_username = "jburns"
  ssh_password = "vagrant"
  ssh_port = 22
  ssh_wait_timeout = "10000s"
  shutdown_command = "echo 'jburns'|sudo -S shutdown -P now"
}

build {
  sources = [
    "source.qemu.centos9"
  ]
}

headless = true -- was required as gtk is the default and did not work. I did not dig into this any further as headless should be fine
accelerator='tcg' -- or omitting the accelerator parameter is required. This defaults to KVM which is x86 and does not work on m1/m2s.
qemu_binary = "/opt/homebrew/bin/qemu-system-aarch64" -- This is required as by default since this targets KVM it tries to launch the x86 build of QEMU which will not work. Overriding this will target the correct arch for m1/m2
machine_type = "virt" -- Because we change the qemu_binary we have to update this option as the default does not work. This is concerning as it shows the plugin is opinionated towards x86 qemu and many options could need to be changed.

This is where my investigation was stopped. First this is hacky and not how this builder is intended to work. Secondly I never got it to work. With these changes I was running into this error 2023/05/15 14:14:23 packer-builder-qemu plugin: Qemu stderr: qemu-system-aarch64: no function defined to set boot device list for this architecture which from what I could gather was because the machine_type passed does not support the -boot flag that the plugin was trying to execute with. A suggested option was to supply the builder with etk2 bios but this needs to be compiled for you architecture and that is where I figured I am trying to fit a square peg into a round hole.

Vagrant QEMU plugin

Simple example of this worked OOTB and might be a good replacement. Though this is not a true test and we would need to see if we could get this provider to work with an image built by packer which I could never get working.

Parallels

At a glance it works on M1/M2 chips but is a paid product. Looks like we could get 5 seats for $89.99 a year with a 2 year contract. These seats can be reassigned. Parallels is well supported both in Packer and Vagrant. Could be an alternative but has a cost

VMWare

Also well supported with Packer and Vagrant and does work in M1/M2 chips. They do have a Free Personal License that we might be able to leverage for this section as it is for home use, educational purpose or Open Source contributors. Given the bootcamp is non commercial I am interested to see if this could work for us. Otherwise I think cost prohibits this option

In a recent PR (#286) we added metadata about the bootcamp. This metadata allows us to to create some visualizations using chart.js. One of the things collected in the metadata is an array of technologies that are used in each exercise. Usuing this data and chartjs-chart-wordcloud we can create a wordcloud of technologies we use. This would be a good add to the bootcamp landing page

Testing the changes here will depend on the images created in #302

Learning Goal

Crash course on Kubernetes -- This gets covered in a much greater depth later in the bootcamp

The task here is to migrate Exercise 2 to leverage the Github self-hosted runner Artifactory pipeline we have been working with in chapter 2. But this time to deploy the containers created in 2.4 via k8. Ultimately building Spring Pet Clinic on the pods

Learning Goal

Using a pipeline to build and publish Docker images

Previously this was done in a Jenkins pipeline. Switch this to use a GHA, seems straight forward

I have found this; an official plugin for GitHub actions from SonarQube that could make this replacement simple. This should use a simplistic actions as the point of this section is SonarQube,
not GitHub actions. If the plugin is used please include a link or reference so that more information is available, if desired.

I personally think it is fine to leave Jenkins in both of these sections.

Depending on what we decide to do with #305 we might want to update 7.2 to have a brief introduction to Jenkins since that might be the first time it is encountered.

Description

As a pair of fresh 👀, read/do devops bootcamp in order to provide either overall feedback or edits which could include either removing or adding sections to the overall program. Comments will be left below as well as potential changes and/or feedback via DevOps Bootcamp Content Review.

Acceptance Criteria

• Review and/or do DevOps Camp
  • ch1
  • ch2
  • ch3
  • ch4
  • ch5
  • ch6
  • ch7
  • addendum
• Provide potential:
  • add markdown config file; .markdownlint.json
  • various edits / additions

• Add support for renaming files
• Add support for deleting sections
• Add nuclear option (rebuild the entire master record)

We recently reworked chapter 2 of the bootcamp because at this time VirtualBox does not work with M1/M2 macs. VirtualBox is the default provider for Vagrant making the Vagrants sections DOA. Found a Vagrant Plugin that adds QEMU as a provider for VirtualBox. At a glance this looks like it will allow us to still do the Vagrant sections as it is tested on M1 macs and with a CentOS 7 image.

https://github.com/ppggff/vagrant-qemu

Learning Goal

Integrating Maven into Build Pipeline

Previously this leveraged a Jekins plugin that managed Maven releases. Looks like we can move to this GHA https://github.com/marketplace/actions/java-maven-release

This like many of the others uses our GH self-hosted runner Artifactory servers.

Description

Implement cspell into bootcamp using much of what was discovered in the following issue/PR:

• Research alternative spell check packages#265
• #266

Acceptance Criteria

• implement cspell
• test to confirm it's working
• add necessary rules to config file to maintain formatting

Artifactory looks to no longer be free. It has a 14 day trial but that is no good since we ask apprentices to use this server multiple times in the bootcamp.

Sonatype Nexus Repository -- Looks like a popular FOSS alternative

We want to get an estimate on the Bootcamp. To make sure it fits within our 6 month goal. This doc will be our living estimate doc. I hope to get feedback from current apprentices and future apprentices so we can refine our estimates

The EKS section (3.2.7) could use a light refresh and some hints

There has been an effort to get an idea of what is covered in the bootcamp. At a high level we want to know roughly how long the bootcamp takes and what technologies and categories are covered. Initially I was going the route of putting this in a google sheet which works for quick and dirty stuff but ultimately we want this information to be shared with the world and talked about putting this in a blog post.

This kind of sucks as the blog post will not age well. Instead we should come up with a dynamic way to put this metadata in the bootcamp and have visualizations generated on the bootcamp

Learning Goal

Container Introduction

Previous exercise introduced apprentices to containers by containerizing the Jenkins Artifactory servers. Based off #282 let's instead ask them to create a GitHub self-hosted runner and Artifactory in containers.

Might be a helpful starting point ¯_(ツ)_/¯
https://dev.to/pwd9000/create-a-docker-based-self-hosted-github-runner-linux-container-48dh

Title.

Learning Goal

helm create

Update Exercise 4 to create a chart to deploy a GH self-hosted runner. This should leverage the image created in previous chapters

Learning Goal

'Real world' example configuring vm's and communicating between your vms

What it does now

Leverages a Golden Image created in an earlier exercise (centos7 with java installed) to stand up a Jenkins server. Using the same golden image stand up an Artifactory server. Connect the two and build a pipeline that publishes a build artifact to the artifactory instance

What it should go to

Using the Golden Image (For the developer just stand up a centos7 vm locally that should be good enough) make it a self-hosted GitHub runner. Standup another CentOS7 vm and install Artifactory on it. Create workflow that uses jFrog Artifactory action to push to artifactory vm after build of spring pet clinic.

Description

Now that the text-linter job is working against all markdown files, the violations associated with those files need to be resolved. This can be done manually by fixing each such violation, via the .markdownlint.json file, or a combination of the two. Ideally, this is done in collaboration with the Flywheel Team as a whole to ensure we're not simply ignoring all violations via the .markdownlint.json file.

Acceptance Criteria

• All violations have been resolved:
  • manually
  • using the .markdownlint.json file
• reenable glob:

          globs: |
            *.md
            **/*.md

• Update repo so it works
• Update section in bootcamp to reference new repo
• Add section about bucket policies

In the glowing jaguars we due to time constrains skipped exercise 2 in 3.2.6 (ECS Socks Shop). An apprentice briefly attempted this section and reported that the deploy script for ECS did not work. This needs to be reviewed and possibly fixed

https://devops-bootcamp.liatr.io/#/6-infrastructure-configuration-management/6.2-ansible

In this section we are really just using Jenkins as a 'thing to install' with Ansible. Feel like we could pick any number of things but I lean towards a GitHub self-hosted runner.

Title.

We recently added a spell check package to the bootcamp to fix errors easily and have some automation around typos. The package we picked markdown-spellchecker is not well maintained and not very extensible

https://www.npmjs.com/package/markdown-spellcheck
https://www.npmjs.com/package/cspell

Let's explore something like cspell or another well maintained npm spell checker. Things that I am looking for are

• well maintained
• extensible configuration
• pattern support in dictionaries
• git hook on pre-commit
• and then github action on pull request

tasklist

• fork bootcamp
• write build and deploy actions

checks

• is the deployment lib out of date in builtin deploy action?
• is the auto deploy action causing problems across all browsers?

https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html

This is a test ticket please do not delete

Realworld is an outdated set of frontend and backend applications intended to function together, but in actuality are quite difficult to configure to work with one another. This causes an unnecessary blocker, halting the learning process of deploying containers to AWS/Azure. Proposing the creation of a simple, Liatrio managed frontend and backend that serves the same learning purpose as Realworld.

It is mostly used throughout chapter 3 with references in chapter 5. First look is linked below.

https://devops-bootcamp.liatr.io/#/3-cloud-computing/3.2.1-s3-cloudfront?id=create-a-website-using-an-s3-bucket
https://codebase.show/projects/realworld

Learning Goal

Making Go releases with GoReleaser

Pretty straight forward one changing a Jenkins pipeline that builds a Go binary and publishes it to a GitHub repo to a GHA pipeline that does the same thing

Overview

• May need changes for M1 and also value reasons.

I was reviewing the devops-bootcamp repo and realized that we didn’t support local development on it well (globally installing npm packages with vulnerability is ). As a quick and dirty way to get this spun up I leveraged the package choices I found in the liatrio onboarding repo.

The dev dependency that got added was a linter called remark which we use in the onboarding repo. This got me thinking and looking into other linters we can add specifically for spelling, and clarity. But I also think we can reevaluate the markdown linter. A quick search lead me to this post where someone talked about what they thought were good linters and why. https://earthly.dev/blog/markdown-lint/

The way I see this ticket there are a few things to research and decide on:

What linters should we add (I am inclined to say for sure a markdown linter and a spelling linter)

Which linter should we use. I am usually inclined to go with tools that get active development, fit our existing tech stack.

And then add these linters.

I would guess that after adding linters we might find many violations. I would suggest addressing those violations as a fast-follow to keep pr’s segregated

• The link is "Build an image" which links to a docker tutorial. We want the AWS version. Press the docker button in the top left to go back and get the AWS link.
• Run it through Grammerly or other.

Learning Goal: Test automation in a pipeline

Currently: Leverages a Docker container running Jenkins to run automated tests from a forked repo

We should migrate this to setting up a github action that runs your Go unit tests. Then a dependent action that builds your application.

I am not sure if the best practice is to separate these into different workflow files and link them or have them in a single job. Please try to reflect either the industry best practice here or Liatrio's POV

Think it would be cool if we also added a section about status badges for the Automated Tests workflow

Check these

• Go unit tests can be run simply by GitHub actions

Poking around the bootcamp I found an unfinished webdriver file. It would be nice to get some basic smoke tests added to the bootcamp so eventually we can add some automation around running these.

I am not sure if webdriver is the right tool for the job. But this concern is mainly thinking ahead on how this might be automated. My first instinct was to want these tests eventually added to a GitHub action. And I am not sure how this would work in a headless environment (I know webdriver can handle headless environments but can GitHub actions?). If this is overly complicated then maybe checking for a 200 is all we need. Does that happen pre or post merge? If so do we auto rollback?

Maybe the juice isn't worth the squeeze for fully automated regression tests. And maybe we just want to clean up this webdriver file.

TL'DR: there is an incomplete and seemingly unused test file. We should do something about it.