fixing

.github/workflows/image-ci.yml

@@ -1,53 +1,53 @@
-name: image-ci
-
-on:
-  push:
-    branches:
-      - 'github-action'
-    tags:
-      - 'v*'
-
-jobs:
-  build-tag-push:
-    runs-on: ubuntu-latest
-    steps:
-      - name: Checkout
-        uses: actions/checkout@v3
-
-      - name: Docker meta
-        id: meta
-        uses: docker/metadata-action@v4
-        with:
-          images: |
-            sidpalas/devops-directive-docker-course-api-node
-          tags: |
-            type=raw,value=latest
-            type=ref,event=branch
-            type=ref,event=pr
-            type=semver,pattern={{version}}
-            type=semver,pattern={{major}}.{{minor}}
-            type=raw,value={{date 'YYYYMMDD'}}-{{sha}}
-
-      - name: Login to Docker Hub
-        uses: docker/login-action@v2
-        with:
-          username: ${{ secrets.DOCKERHUB_USERNAME }}
-          password: ${{ secrets.DOCKERHUB_TOKEN }}
-
-      - name: Build and push
-        uses: docker/build-push-action@v4
-        with:
-          file: ./06-building-container-images/api-node/Dockerfile.8
-          context: ./05-example-web-application/api-node/
-          push: true
-          tags: ${{ steps.meta.outputs.tags }}
-
-      - name: Run Trivy vulnerability scanner
-        uses: aquasecurity/trivy-action@master
-        with:
-          image-ref: 'sidpalas/devops-directive-docker-course-api-node:latest'
-          format: 'table'
-          exit-code: '1'
-          ignore-unfixed: true
-          vuln-type: 'os,library'
+name: image-ci
+
+on:
+  push:
+    branches:
+      - 'github-action'
+    tags:
+      - 'v*'
+
+jobs:
+  build-tag-push:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v3
+
+      - name: Docker meta
+        id: meta
+        uses: docker/metadata-action@v4
+        with:
+          images: |
+            axellofberg/devops-directive-docker-course-api-node
+          tags: |
+            type=raw,value=latest
+            type=ref,event=branch
+            type=ref,event=pr
+            type=semver,pattern={{version}}
+            type=semver,pattern={{major}}.{{minor}}
+            type=raw,value={{date 'YYYYMMDD'}}-{{sha}}
+
+      - name: Login to Docker Hub
+        uses: docker/login-action@v2
+        with:
+          username: ${{ secrets.DOCKERHUB_USERNAME }}
+          password: ${{ secrets.DOCKERHUB_TOKEN }}
+
+      - name: Build and push
+        uses: docker/build-push-action@v4
+        with:
+          file: ./06-building-container-images/api-node/Dockerfile.8
+          context: ./05-example-web-application/api-node/
+          push: true
+          tags: ${{ steps.meta.outputs.tags }}
+
+      - name: Run Trivy vulnerability scanner
+        uses: aquasecurity/trivy-action@master
+        with:
+          image-ref: 'sidpalas/devops-directive-docker-course-api-node:latest'
+          format: 'table'
+          exit-code: '1'
+          ignore-unfixed: true
+          vuln-type: 'os,library'
           severity: 'CRITICAL'

.gitignore

@@ -1,7 +1,7 @@
-**/node_modules
-**/.npm
-*.un~
-*.json~
-
-.DS_Store
+**/node_modules
+**/.npm
+*.un~
+*.json~
+
+.DS_Store
 **/tmp

.vscode/settings.json

@@ -0,0 +1,3 @@
+{
+    "git.ignoreLimitWarning": true
+}

01-history-and-motivation/README.md

@@ -1,74 +1,74 @@
-# History and Motivation
-
-<!-- no toc -->
-  - [What is a container?](#what-is-a-container)
-  - [History of virtualization](#history-of-virtualization)
-    - [Bare Metal](#bare-metal)
-    - [Virtual Machines](#virtual-machines)
-    - [Containers](#containers)
-    - [Tradeoffs](#tradeoffs)
-
----
-
-## What is a container?
-
-A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application (https://www.docker.com/resources/what-container/).
-
-## History of virtualization
-
-### Bare Metal
-
-Before virtualization was invented, all programs ran directly on the host system. The terminology many people use for this is "bare metal". While that sounds fancy and scary, you are almost certainly familiar with running on bare metal because that is what you do whenever you install a program onto your laptop/desktop computer. 
-
-![](./readme-assets/bare-metal.jpg)
-
-With a bare metal system, the operating system, binaries/libraries, and applications are installed and run directly onto the physical hardware.
-
-This is simple to understand and direct access to the hardware can be useful for specific configuration, but can lead to:
-- Hellish dependency conflicts
-- Low utilization efficiency
-- Large blast radius
-- Slow start up & shut down speed (minutes)
-- Very slow provisioning & decommissioning (hours to days)
-
----
-
-### Virtual Machines
-
-Virtual machines use a system called a "hypervisor" that can carve up the host resources into multiple isolated virtual hardware configuration which you can then treat as their own systems (each with an OS, binaries/libraries, and applications).
-
-![](./readme-assets/virtual-machine.jpg)
-
-This helps improve upon some of the challenges presented by bare metal:
-
-- No dependency conflicts
-- Better utilization efficiency
-- Small blast radius
-- Faster startup and shutdown (minutes)
-- Faster provisioning & decommissioning (minutes)
-
----
-
-### Containers
-
-Containers are similar to virtual machines in that they provide an isolated environment for installing and configuring binaries/libraries, but rather than virtualizing at the hardware layer containers use native linux features (cgroups + namespaces) to provide that isolation while still sharing the same kernel.
-
-![](./readme-assets/container.jpg)
-
-This approach results in containers being more "lightweight" than virtual machines, but not providing the save level of isolation:
-
-- No dependency conflicts
-- Even better utilization efficiency
-- Small blast radius
-- Even faster startup and shutdown (seconds)
-- Even faster provisioning & decommissioning (seconds)
-- Lightweight enough to use in development!
-
----
-
-### Tradeoffs
-
-![](./readme-assets/tradeoffs.jpg)
-
-***Note:*** There is much more nuance to “performance” than this chart can capture. A VM or container doesn’t inherently sacrifice much performance relative to the bare metal it runs on, but being able to have more control over things like connected storage, physical proximity of the system relative to others it communicates with, specific hardware accelerators, etc… do enable performance tuning
-
+# History and Motivation
+
+<!-- no toc -->
+  - [What is a container?](#what-is-a-container)
+  - [History of virtualization](#history-of-virtualization)
+    - [Bare Metal](#bare-metal)
+    - [Virtual Machines](#virtual-machines)
+    - [Containers](#containers)
+    - [Tradeoffs](#tradeoffs)
+
+---
+
+## What is a container?
+
+A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application (https://www.docker.com/resources/what-container/).
+
+## History of virtualization
+
+### Bare Metal
+
+Before virtualization was invented, all programs ran directly on the host system. The terminology many people use for this is "bare metal". While that sounds fancy and scary, you are almost certainly familiar with running on bare metal because that is what you do whenever you install a program onto your laptop/desktop computer. 
+
+![](./readme-assets/bare-metal.jpg)
+
+With a bare metal system, the operating system, binaries/libraries, and applications are installed and run directly onto the physical hardware.
+
+This is simple to understand and direct access to the hardware can be useful for specific configuration, but can lead to:
+- Hellish dependency conflicts
+- Low utilization efficiency
+- Large blast radius
+- Slow start up & shut down speed (minutes)
+- Very slow provisioning & decommissioning (hours to days)
+
+---
+
+### Virtual Machines
+
+Virtual machines use a system called a "hypervisor" that can carve up the host resources into multiple isolated virtual hardware configuration which you can then treat as their own systems (each with an OS, binaries/libraries, and applications).
+
+![](./readme-assets/virtual-machine.jpg)
+
+This helps improve upon some of the challenges presented by bare metal:
+
+- No dependency conflicts
+- Better utilization efficiency
+- Small blast radius
+- Faster startup and shutdown (minutes)
+- Faster provisioning & decommissioning (minutes)
+
+---
+
+### Containers
+
+Containers are similar to virtual machines in that they provide an isolated environment for installing and configuring binaries/libraries, but rather than virtualizing at the hardware layer containers use native linux features (cgroups + namespaces) to provide that isolation while still sharing the same kernel.
+
+![](./readme-assets/container.jpg)
+
+This approach results in containers being more "lightweight" than virtual machines, but not providing the save level of isolation:
+
+- No dependency conflicts
+- Even better utilization efficiency
+- Small blast radius
+- Even faster startup and shutdown (seconds)
+- Even faster provisioning & decommissioning (seconds)
+- Lightweight enough to use in development!
+
+---
+
+### Tradeoffs
+
+![](./readme-assets/tradeoffs.jpg)
+
+***Note:*** There is much more nuance to “performance” than this chart can capture. A VM or container doesn’t inherently sacrifice much performance relative to the bare metal it runs on, but being able to have more control over things like connected storage, physical proximity of the system relative to others it communicates with, specific hardware accelerators, etc… do enable performance tuning
+