liveBook · Manning

GitHub Actions

As explained in Road to Kubernetes

GitHub Actions is a GitHub automation platform for defining and running workflows in response to repository events or on specified schedules.

Repeated deployment steps are easy to forget and hard to reproduce on a new server. GitHub Actions runs code on GitHub’s servers according to workflow files in a repository. Here, it provides the automation that connects code changes to testing, server configuration, and deployment. section 4.0 section 4.1

To run a first workflow:

  • Create a GitHub repository and add a YAML file under .github/workflows/ on its default branch. section 4.1.1
  • Declare when it runs, such as on a push or through a manual workflow_dispatch request. Define a job, its runner, and the steps to execute. section 4.1.1
  • Commit and push the file, then inspect or manually start a run from the repository’s Actions tab. section 4.1.1
Listing 4.2 Hello World with GitHub Actions
name: Hello World
on:
  workflow_dispatch:
  push:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Hello World
      run: echo "Hello World"

The Hello World workflow shows the complete starting pattern: push and manual triggers, an ubuntu-latest runner, a checkout step, and an echo command. section 4.1.1

A workflow can do more than print a message. To install NGINX on a remote Ubuntu server, create a dedicated SSH key pair, install its public key on the server, and store the private key as a repository Actions secret. Store the server’s IP address as a secret too. Workflow steps can read them with expressions such as ${{ secrets.SSH_PRIVATE_KEY }} without placing their values in the repository. section 4.1.2 section 4.1.5

Listing 4.4 Installing NGINX with GitHub Actions
name: Install NGINX
on:
  workflow_dispatch:
  push:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Configure the SSH Private Key Secret
      run: |
        mkdir -p ~/.ssh/
        echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa
        chmod 600 ~/.ssh/id_rsa
    - name: Set Strict Host Key Checking
      run: echo "StrictHostKeyChecking=no" > ~/.ssh/config
    - name: Install NGINX
      run: |
        export MY_HOST="${{ secrets.AKAMAI_INSTANCE_IP_ADDRESS }}"
        ssh root@$MY_HOST sudo apt update
        ssh root@$MY_HOST sudo apt install nginx -y

The NGINX workflow writes the stored private key to the runner with restricted permissions, then uses SSH to update the remote system and install NGINX. Keep private keys out of committed files. section 4.1.5

For fuller deployments, a workflow can run Ansible to configure a Python or Node.js application and its server. Later, the same automation approach builds and pushes containers and can install Docker and Docker Compose on a virtual machine. The workflow is the repeatable entry point; tools such as Ansible and Docker perform the configuration or packaging work. section 4.0 section 4.2.4 section 6.0 section 7.3.2

How Road to Kubernetes covers it

How deep it goes
Works from a first YAML workflow through secrets and remote installation, then reuses workflows for Ansible and containers.
Examples
Uses a Hello World job, an SSH-based NGINX installation, and Python and Node.js deployment workflows.
What it assumes
Assumes a GitHub repository; introduces workflow YAML from a Hello World example and calls for SSH keys when accessing a remote server.
What you can do after
Build it from scratch: create a repository workflow, add secrets, and automate commands on a remote server.
How it connects
Connects CI/CD pipelines with Git, SSH secrets, Ansible, Docker, and Docker Compose.

Also explained in

Compare how 10 books explain GitHub Actions →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Road to Kubernetes. The section links point to the parts of the book it draws on.