DEV Community

Cover image for DevOps by Doing: Setting Up a Complete Modern DevOps Environment — Part 2
John Ogbonna
John Ogbonna

Posted on

DevOps by Doing: Setting Up a Complete Modern DevOps Environment — Part 2

#docker #cicd #tutorial #devops

What this part covers

In Part 1, we built the foundation: Git setup, Node.js app, dependencies, and automated tests.

In Part 2, we’ll take the next big steps toward a production-ready setup by:

  • Creating a .gitignore file

  • Setting up a .env.example for environment variables

  • Adding ESLint for code quality

  • Writing a Dockerfile to containerize our app

  • Creating a .dockerignore to slim images

  • Using Docker Compose for local development

  • Running & testing the app in Docker

  • Setting up GitHub repository + pushing code

  • Configuring GitHub Actions CI/CD pipeline for build + test

  • Deploying to GitHub (first automated deployment)

  • Monitoring build/deployment success

By the end of this article, you’ll have your project running in Docker, connected to GitHub, and building automatically via CI/CD.

Step 1: GitHub Actions CI/CD Pipeline

What this step does

We’re now moving from local development into automation. In this step, we’ll create a GitHub Actions pipeline that:

  • Runs linting, tests, and security audits on every push and pull request.

  • Builds and pushes Docker images to GitHub’s container registry (GHCR).

  • Runs a vulnerability scan against the built image.

  • Deploys automatically to staging (develop branch) and production (main branch).

This is the backbone of modern DevOps: CI/CD automation that ensures code is tested, packaged, secured, and ready for deployment — with no manual intervention required.

  • Create workflow directory: 
# Create the GitHub Actions directory structure
mkdir -p github/workflows
Enter fullscreen mode Exit fullscreen mode
  • Create ci.yml: 
touch .github/workflows/ci.yml
Enter fullscreen mode Exit fullscreen mode
  • Create the pipeline definition

Inside .github/workflows/ci.yml, add the following:

name: CI/CD Pipeline

on:
  push:
    branches: [ main, develop ]
    tags: [ 'v*' ]
  pull_request:
    branches: [ main ]

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  test:
    name: Test & Lint
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [20, 22]

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run linting
        run: npm run lint

      - name: Run tests
        run: npm test

      - name: Security audit
        run: npm audit --audit-level=critical || echo "Audit completed with warnings"

  build:
    name: Build & Push Image
    runs-on: ubuntu-latest
    needs: test
    if: github.event_name == 'push'

    permissions:
      contents: read
      packages: write
      security-events: write

    outputs:
      image-tag: ${{ steps.meta.outputs.tags }}
      image-digest: ${{ steps.build.outputs.digest }}

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3
        with:
          platforms: linux/amd64,linux/arm64

      - name: Log in to Container Registry
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Extract metadata
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
          tags: |
            type=ref,event=branch
            type=ref,event=pr
            type=semver,pattern={{version}}
            type=semver,pattern={{major}}.{{minor}}
            type=sha,prefix={{branch}}-
            type=raw,value=${{ github.run_id }}
            type=raw,value=latest,enable={{is_default_branch}}
          labels: |
            org.opencontainers.image.title=DevOps Lab 2025
            org.opencontainers.image.description=Modern Node.js DevOps application

      - name: Build and push Docker image
        id: build
        uses: docker/build-push-action@v5
        with:
          context: .
          platforms: linux/amd64,linux/arm64
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          cache-from: type=gha
          cache-to: type=gha,mode=max
          target: production

      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@0.24.0
        with:
          image-ref: ${{ steps.meta.outputs.tags }}
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'
        continue-on-error: true

      - name: Upload Trivy scan results
        uses: github/codeql-action/upload-sarif@v3
        if: always() && hashFiles('trivy-results.sarif') != ''
        with:
          sarif_file: 'trivy-results.sarif'

  deploy-staging:
    name: Deploy to Staging
    runs-on: ubuntu-latest
    needs: build
    if: github.ref == 'refs/heads/develop'
    environment: staging

    steps:
      - name: Deploy to Staging
        run: |
          echo "🚀 Deploying to staging environment..."
          echo "Image: ${{ needs.build.outputs.image-tag }}"
          echo "Digest: ${{ needs.build.outputs.image-digest }}"
          # Add your staging deployment commands here (kubectl, helm, etc.)

  deploy-production:
    name: Deploy to Production
    runs-on: ubuntu-latest
    needs: build
    if: github.ref == 'refs/heads/main'
    environment: production

    steps:
      - name: Deploy to Production
        run: |
          echo "🎯 Deploying to production environment..."
          echo "Image: ${{ needs.build.outputs.image-tag }}"
          echo "Digest: ${{ needs.build.outputs.image-digest }}"
          # Add your production deployment commands here
Enter fullscreen mode Exit fullscreen mode

This setup:

  • Ensures we only build/test on pushes to main or develop, pull requests to main, or tagged releases.
  • Runs in Node 20 and 22 to validate across multiple versions

  • For the building and pushing of Docker Images, it only runs on push events and after tests pass it:

    • Uses Buildx for multi-arch images (amd64 + arm64).
    • Pushes to GitHub Container Registry.
    • Adds labels and tags for traceability.
    • Runs Trivy for vulnerability scanning.

  • Separates staging and production deployments by branch:

    • develop → staging
    • main → production

ci steps

Why this matters

By the end of this step, you now have:
✅ Automated linting, tests, and audits on every change.
✅ Docker images built and pushed to GHCR automatically.
✅ Security scans integrated directly into CI/CD.
✅ Branch-based deployments ready for staging and production.

This is the minimum baseline for modern DevOps — continuous integration, containerized builds, automated deployments, and built-in security.

Step 2: Dockerfile

What this step does

The Dockerfile defines how to package your application into a container image that can run consistently anywhere — locally, in CI/CD pipelines, or in cloud environments.

In this step, we’ll create a production-ready Dockerfile that:

  • Uses multi-stage builds to keep images small.

  • Runs as a non-root user for security.

  • Sets up health checks for monitoring.

  • Includes signal handling for clean shutdowns.

  • This makes your app portable, secure, and reliable.

Create Dockerfile

Enter:

touch Dockerfile
Enter fullscreen mode Exit fullscreen mode

In Dockerfile, Paste:

# Multi-stage build for optimized image
FROM node:20-alpine AS dependencies

# Update packages for security
RUN apk update && apk upgrade --no-cache

WORKDIR /app

# Copy package files first for better caching
COPY package*.json ./

# Install only production dependencies
RUN npm ci --only=production && npm cache clean --force


# Production stage  
FROM node:20-alpine AS production

# Update packages and install necessary tools
RUN apk update && apk upgrade --no-cache && \
    apk add --no-cache curl dumb-init && \
    rm -rf /var/cache/apk/*

# Create non-root user with proper permissions
RUN addgroup -g 1001 -S nodejs && \
    adduser -S nodeuser -u 1001 -G nodejs

WORKDIR /app

# Copy dependencies from previous stage with proper ownership
COPY --from=dependencies --chown=nodeuser:nodejs /app/node_modules ./node_modules

# Copy application code with proper ownership
COPY --chown=nodeuser:nodejs package*.json ./
COPY --chown=nodeuser:nodejs app.js ./

# Switch to non-root user
USER nodeuser

# Expose port
EXPOSE 3000

# Health check with proper timing for Node.js startup
HEALTHCHECK --interval=30s --timeout=10s --start-period=15s --retries=3 \
  CMD curl -f http://localhost:3000/health || exit 1

# Use dumb-init for proper signal handling in containers
ENTRYPOINT ["dumb-init", "--"]

# Start application
CMD ["npm", "start"]
Enter fullscreen mode Exit fullscreen mode

Dockerfile Steps

Dockerfile Explained

Dependencies Stage:

  • Based on node:20-alpine for a minimal footprint.

  • Installs only production dependencies.

  • Cleans up cache to keep size small.

Production Stage

  • Installs required tools (curl, dumb-init).

  • Creates a non-root user (nodeuser) with proper permissions.

  • Copies dependencies and app code with correct ownership.

  • Defines a health check endpoint (/health).

  • Uses dumb-init as the entrypoint for proper signal handling.

Why this matters

By containerizing your app with this Dockerfile, you gain:
✅ Consistency: Same environment across dev, CI/CD, and production.
✅ Security: Runs as non-root with patched Alpine base image.
✅ Reliability: Health checks ensure containers are restarted if unhealthy.
✅ Efficiency: Multi-stage builds keep images lean.

Step 3: Essential Configuration Files

What this step does

Configuration files are the unsung heroes of a DevOps project. They define what to ignore, how tools behave, and what settings your project expects.

In this step, we’ll set up:

  • .dockerignore – to keep Docker images lean.

  • .gitignore – to avoid committing unnecessary or sensitive files.

  • .env.example – a template for environment variables.

  • .eslintrc.js – to enforce coding standards.

Create .dockerignore

  • This file ensures your Docker builds don’t copy unnecessary files into the image, making builds faster and images smaller 
node_modules
npm-debug.log*
.git
.github
.env
.env.local
.env.*.local
logs
*.log
coverage
.nyc_output
.vscode
.idea
*.swp
*.swo
.DS_Store
Thumbs.db
README.md
tests/
jest.config.js
.eslintrc*
Enter fullscreen mode Exit fullscreen mode

Create .gitignore 

# Dependencies
node_modules/
npm-debug.log*

# Runtime data
pids
*.pid
*.seed
*.pid.lock

# Coverage
coverage/
.nyc_output

# Environment variables
.env
.env.local
.env.*.local

# Logs
logs
*.log

# IDE
.vscode/
.idea/
*.swp
*.swo

# OS
.DS_Store
Thumbs.db
Enter fullscreen mode Exit fullscreen mode

Create .env.example 

# Server Configuration
PORT=3000
NODE_ENV=production

# Logging
LOG_LEVEL=info
Enter fullscreen mode Exit fullscreen mode

Create ESLint configuration:

create .eslintrc.js

module.exports = {
  env: {
    node: true,
    es2021: true,
    jest: true
  },
  extends: ['eslint:recommended'],
  parserOptions: {
    ecmaVersion: 12,
    sourceType: 'module'
  },
  rules: {
    'no-console': 'off',
    'no-unused-vars': ['error', { 'argsIgnorePattern': '^_' }]
  }
};
Enter fullscreen mode Exit fullscreen mode

config files

Step 4: Docker Compose for Development

What this step does

While a Dockerfile defines how to build your app’s container, Docker Compose makes it easy to run multiple services together (like your app + a database).

With one command, you can spin up your entire development environment.

  • Create docker-compose.yml 
version: '3.8'

services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=development
      - PORT=3000
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 10s
Enter fullscreen mode Exit fullscreen mode

Start your app with:

docker-compose up --build
Enter fullscreen mode Exit fullscreen mode

(First stop the app if started with npm)

Stop it with:

docker-compose down
Enter fullscreen mode Exit fullscreen mode

docker

Step 4: Test Everything Locally

What this step does: Shows you how to actually run and test your application locally before deploying it.

Install and Test Locally

# Install all dependencies from package.json
npm install

# Run your test suite to make sure everything works
npm test

# Start the application server
npm start
Enter fullscreen mode Exit fullscreen mode

What you’ll see:

  • Tests should pass with green checkmarks:
  • ✓ GET / should return welcome page

Server starts and shows:
🚀 Server running at http://localhost:3000/

server running

Test endpoints (in a new terminal window):

curl http://localhost:3000/         # Homepage
curl http://localhost:3000/health   # Health check JSON
curl http://localhost:3000/info     # System info JSON  
curl http://localhost:3000/metrics  # Prometheus metrics
Enter fullscreen mode Exit fullscreen mode

Results of test:
endpoint test

Docker Commands

Use these to test your image and container directly (great for debugging fundamentals).

# Build image
docker build -t my-devops-app:latest .

# Run container
docker run -d \
  --name my-devops-container \
  -p 3000:3000 \
  --restart unless-stopped \
  my-devops-app:latest

# Check container status
docker ps
docker logs my-devops-container

# Test health check
curl http://localhost:3000/health

# Stop container
docker stop my-devops-container
docker rm my-devops-container
Enter fullscreen mode Exit fullscreen mode

Docker Compose Commands

Use these for day-to-day development or when you have multiple services.

# Start all services defined in docker-compose.yml
docker-compose up -d

# View real-time logs from all services
docker-compose logs -f

# Stop all services and clean up
docker-compose down
Enter fullscreen mode Exit fullscreen mode

Step 5: Deploy to GitHub

What this step does: Commits your code to Git and pushes it to GitHub so the automated CI/CD pipeline can start working.

Initial Commit

# Add all files to Git staging area
git add .

# Create your first commit with a descriptive message
git commit -m "Initial commit: Complete DevOps setup with working CI/CD"
Enter fullscreen mode Exit fullscreen mode

Connect to GitHub

⚠️ Before running these commands:

  • Go to GitHub.com and create a new repository called my-devops-project.

  • Do not initialize it with a README, .gitignore, or license (we already created those).

  • Copy the repository URL from GitHub.

  • Replace YOUR_GITHUB_USERNAME in the commands below with your actual username.

# Set main as the default branch
git branch -M main

# Connect to your GitHub repository (UPDATE THIS URL!)
git remote add origin https://github.com/YOUR_GITHUB_USERNAME/my-devops-project.git

# Push your code to GitHub for the first time
git push -u origin main
Enter fullscreen mode Exit fullscreen mode

What You’ll See

  • Your code appears in your new GitHub repository.

  • The CI/CD pipeline kicks in automatically (thanks to the GitHub Actions workflow you added earlier).

Step 6: Fix CI Security Scan Errors

The Problem:
When the pipeline first runs, the security scanner fails with this error:

failed to parse the image name: could not parse reference: ghcr.io/USERNAME/my-devops-project:latest

This happened because the workflow was hardcoding :latest as the image tag. At the time of the scan, that tag didn’t exist yet in the GitHub Container Registry, so Trivy couldn’t find or parse the image reference.

The Fix:
Instead of scanning :latest, we need to scan the exact image tag that was built and pushed by the build job. GitHub Actions makes this available via the job output needs.build.outputs.image-tag.

Edit .github/workflows/ci.yml and replace the security-scan section with:

    security-scan:
  name: Security Scan
  runs-on: ubuntu-latest
  needs: build
  if: github.event_name == 'push' && github.ref == 'refs/heads/main'

  steps:
    - name: Run Trivy vulnerability scanner
      uses: aquasecurity/trivy-action@master
      with:
        image-ref: ${{ needs.build.outputs.image-tag }}
        format: 'sarif'
        output: 'trivy-results.sarif'

    - name: Upload Trivy scan results
      uses: github/codeql-action/upload-sarif@v3
      with:
        sarif_file: 'trivy-results.sarif'
Enter fullscreen mode Exit fullscreen mode

Create the Staging Environment in GitHub

  • Go to your repo Settings
    repo Settings

  • Go to Environments, click new environment.
    click new environment

  • Name it: staging

  • Save.
    staging

In VS Save and Commit Your Code Changes

# Stage changes
git add .github/workflows/ci.yml
Enter fullscreen mode Exit fullscreen mode 
# Commit with a clear message
git commit -m "Fixed security scan to use build job image tag"
Enter fullscreen mode Exit fullscreen mode 
# Push to GitHub
git push origin main
Enter fullscreen mode Exit fullscreen mode

push to github

Once pushed, GitHub Actions will re-run the pipeline and Trivy will correctly scan the newly built image.

Step 7: Kubernetes Deployment Configurations

What this step does: Defines how your application should run in Kubernetes for both staging and production environments, including the number of replicas, resource limits, and health checks.

  • Create directories 
# Create directories for Kubernetes configurations
mkdir -p k8s/staging k8s/production
Enter fullscreen mode Exit fullscreen mode
  • Create Staging Deployment

Create k8s/staging/deployment.yml:

⚠️ IMPORTANT: Update YOUR_GITHUB_USERNAME and YOUR_REPO_NAME in the image URL.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: devops-app-staging
  namespace: staging
spec:
  replicas: 2
  selector:
    matchLabels:
      app: devops-app
      environment: staging
  template:
    metadata:
      labels:
        app: devops-app
        environment: staging
    spec:
      containers:
      - name: app
        image: ghcr.io/YOUR_GITHUB_USERNAME/YOUR_REPO_NAME:latest
        ports:
        - containerPort: 3000
        env:
        - name: NODE_ENV
          value: "staging"
        - name: PORT
          value: "3000"
        livenessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 5
          periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: devops-app-service-staging
  namespace: staging
spec:
  selector:
    app: devops-app
    environment: staging
  ports:
  - protocol: TCP
    port: 80
    targetPort: 3000
  type: LoadBalancer
Enter fullscreen mode Exit fullscreen mode
  • Create Production Deployment

Create k8s/production/deployment.yml:

⚠️ IMPORTANT: Update YOUR_GITHUB_USERNAME and YOUR_REPO_NAME in the image URL.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: devops-app-production
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: devops-app
      environment: production
  template:
    metadata:
      labels:
        app: devops-app
        environment: production
    spec:
      containers:
      - name: app
        image: ghcr.io/YOUR_GITHUB_USERNAME/YOUR_REPO_NAME:latest
        ports:
        - containerPort: 3000
        env:
        - name: NODE_ENV
          value: "production"
        - name: PORT
          value: "3000"
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "200m"
        livenessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 5
          periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: devops-app-service-production
  namespace: production
spec:
  selector:
    app: devops-app
    environment: production
  ports:
  - protocol: TCP
    port: 80
    targetPort: 3000
  type: LoadBalancer
Enter fullscreen mode Exit fullscreen mode

Update the k8s/production/deployment.yml as such
deployment.yml

✅ Key Notes:

  • Namespaces: staging and production isolate environments.

  • Replicas: Staging uses 2 replicas; production uses 3 for high availability.

  • Probes: livenessProbe and readinessProbe ensure containers are healthy before traffic is routed.

  • Resources (Production only): CPU/memory requests and limits prevent resource exhaustion.

  • Services: Both use LoadBalancer to expose the application externally.

Step 8: Complete Deployment Workflow

What this step does: Demonstrates the full CI/CD process with branch-based deployments to staging and production, along with monitoring.

1. Branch-based Deployment Strategy

Branch Action
develop Automatically deploys to staging environment
main Automatically deploys to production environment
Pull requests Run tests only (no deployment)

2. Deploy Changes

Deploy to Staging 

# Create and switch to develop branch
git checkout -b develop

# Make your changes, then commit and push
git add .
git commit -m "Add new feature"
git push origin develop
Enter fullscreen mode Exit fullscreen mode

What happens:

  • GitHub Actions automatically builds the image.

  • Runs security scans and tests.

  • Deploys the app to staging (staging namespace in Kubernetes).

3.Deploy to Production

When you’re ready to release:

# Switch to main branch
git checkout main

# Merge changes from develop
git merge develop

# Push to trigger production deployment
git push origin main
Enter fullscreen mode Exit fullscreen mode

production deployment

What happens:

  • GitHub Actions runs the full pipeline.

  • Deploys the app to production (default namespace in Kubernetes).

🔎 Monitor Deployments

Check GitHub Actions status

👉 https://github.com/YOUR_GITHUB_USERNAME/YOUR_REPO_NAME/actions,
replace YOUR_GITHUB_USERNAME and YOUR_REPO_NAME accordingly

Check your container registry

👉https://github.com/YOUR_GITHUB_USERNAME/YOUR_REPO_NAME/pkgs/container/my-devops-project
replace YOUR_GITHUB_USERNAME and YOUR_REPO_NAME accordingly

Test your deployed applications 

# Staging health check
curl https://your-staging-url.com/health

# Production health check
curl https://your-production-url.com/health
Enter fullscreen mode Exit fullscreen mode

🎯 Conclusion

In this second part of DevOps by Doing, we took our project beyond the basics and built out a modern CI/CD pipeline with GitHub Actions, Docker, and Kubernetes.

*We covered how to: *

  • ✅ Automate testing and linting across multiple Node.js versions
  • ✅ Build and publish Docker images to GitHub Container Registry (GHCR)
  • ✅ Deploy automatically to a staging environment from the develop branch
  • ✅ Secure production deployments on the main branch with environment protections

With these steps, you now have a complete DevOps workflow: from writing code, to testing, to building, to deploying in a controlled and repeatable way.

This isn’t just theory—it’s the exact type of pipeline used in modern production teams. By now, you should feel confident that every push to your repo can be tested, built, and deployed automatically. That’s the heart of DevOps by Doing.

Top comments (0)