Docker on Janik von Rotz

Move Docker data directory to new location

Tue, 30 Mar 2021 22:30:50 +0200

The standard data directory used for docker is /var/lib/docker, and since this directory will store all your images, volumes, etc. it can become quite large.

Follow the steps below to move the Docker data directory to a new location. This makes especially sense if you want to avoid running out of disk space on your root partition.

Stop the Docker deamon.

sudo service docker stop

Create a config file /etc/docker/daemon.json

{ 
   "data-root": "/path/to/your/docker" 
}

Copy the current directory to the new directory.

sudo cp -rp /var/lib/docker /path/to/your/docker

Rename the old directory.

sudo mv /var/lib/docker /var/lib/docker.old

Restart the Docker deamon.

sudo service docker start

Test if all services work as expected.

If everything is good, remove the old Docker directory.

sudo rm -rf /var/lib/docker.old

Backup Docker volumes with this script

Tue, 18 Aug 2020 21:38:34 +0200

The official Docker documentation has section about container backup. This section tells you how to backup an attached volume and the command to do so is pretty elaborate. For automating backups you don’t want to script parametrized commands such as this one. A simple script will do the job.

Here is a script that I use to backup all mounted volumes from a running container.

docker-volume-backup

#!/bin/bash

# Exit script if command fails
set -e

# Display Help
Help() {
  echo
  echo "docker-volume-backup"
  echo "####################"
  echo
  echo "Description: Backup docker volumes."
  echo "Syntax: docker-volume-backup [-v|-a|-o|-c|help]"
  echo "Example: docker-volume-backup -v postgres_data01 -o /tmp -c postgres01"
  echo "options:"
  echo "  -v    Comma-separated list of volume names."
  echo "  -a    Backup all volumes."
  echo "  -o    Output directory. Defaults to '/var/tmp'"
  echo "  -c    Docker container name."
  echo "  help  Show docker-volume-backup manual."
  echo
}

# Show help and exit
if [[ $1 == 'help' ]]; then
    Help
    exit
fi

# Process params
while getopts ":a :c: :v: :o:" opt; do
  case $opt in
    a) ALL='true'
    ;;
    c) CONTAINER="$OPTARG"
    ;;
    v) VOLUMES="$OPTARG"
    ;;
    o) DIR="$OPTARG"
    ;;
    \?) echo "Invalid option -$OPTARG" >&2
    Help
    exit;;
  esac
done

# Fallback to environment vars and default values
: ${DIR:='/var/tmp'}

# Verify variables
[[ -z "$VOLUMES" ]] && [[ -z "$ALL" ]] && { echo "Parameter -v or -a|volumes or all must be set" ; exit 1; }
[[ -z "$DIR" ]] && { echo "Parameter -d|dir is empty" ; exit 1; }
[[ -z "$CONTAINER" ]] && { echo "Parameter -c|container is empty" ; exit 1; }

if $ALL ; then
  # Get all volumes from docker container
  VOLUME_LIST=($(docker inspect -f '{{ range .Mounts }}{{ .Name }} {{ end }}' $CONTAINER))

  # Concate volume list
  printf -v VOLUMES '%s,' "${VOLUME_LIST[@]}"
  VOLUMES="${VOLUMES%,}"
fi

if [[ ! -z $VOLUMES ]] ; then
  # Split volumes param values
  VOLUME_LIST=($(echo $VOLUMES | tr "," "\n"))
fi

# Create backup folder
mkdir -p ${DIR}/${CONTAINER}

# Cleanup backup folder
rm -rf ${DIR}/${CONTAINER}/*

# Create dump with docker for each database
for VOLUME in "${VOLUME_LIST[@]}"
do
  echo "Run backup for Docker volume $VOLUME"
  docker run --rm -v $VOLUME:/_data  -v ${DIR/./$(PWD)}/${CONTAINER}:/backup ubuntu tar cf /backup/$VOLUME.tar /_data
done

# Notify if backup has finished
echo "The Docker volume backup has finished: ${DIR}/${CONTAINER}/{${VOLUMES}}.tar"

To get the latest version of this see the Ansible Playbooks projects.

Build multiple Docker image from Yarn workspace packages

Fri, 13 Dec 2019 18:17:28 +0100

If you decide to manage your node application repository as a monorepo you sure heard about Yarn workspaces. Yarn has an out-of-the-box support for managing multiple packages in a single codebase. Using yarn workspaces package dependencies can be centralized and packages can reference each other. Tasks can be executed for all packages at once. It solves various build related problems for a monorepo.

However, if you want to build docker images for one package only things start to become more complicated. Let’s assume we have a workspace with the following configuration:

package.json

{
  "name": "example",
  "version": "1.0.0",
  "scripts": {
    ...
  },
  "private": true,
  "workspaces": ["api", "app", "mongo"],
  "author": "Janik von Rotz",
  "license": "MIT"
}

There are three packages: api, app and mongo.

The api and app packages can be run independently.

However, the api package depends on the mongo package.

api/package.json

{
  "name": "api",
  "version": "1.0.0",
  "scripts": {
    ...
  },
  "dependencies": {
    ...
    "mongo": "1.0.0"
  },
...

As you can see package dependencies do not differ from npm dependencies.

Assuming we would like to build a docker image for the api package, we need to ensure that the app code does not end up on the image. Usually one would simply cd api;docker build ., but here we need extra preparation to resolve the "mongo": "1.0.0" package dependency.

The solution I came up with is not extraordinary. I decided to build the image from the root folder. First I copy the workspace config. Then copy the required packages and build them using the yarn workspace command. Finally I switch the work dir into the package folder and start the server.

This is the Docker file for the api package:

api/Dockerfile

FROM node:10-alpine

# Create app directory
WORKDIR /usr/src/

# Copy workspace config
COPY ./package*.json .

# Copy packages
COPY ./api ./api
COPY ./mongo ./mongo

# Install dependencies for packages
RUN yarn workspace mongo install
RUN yarn workspace api install

# Run the app
WORKDIR /usr/src/api
EXPOSE 3000
CMD ["yarn", "start"]

The image is built by running the command docker build -t api:1.0.0 -f api/Dockerfile . from the root folder.

In similar fashion docker files can be build for the other packages.

Deploy ELK stack with Ansible and Docker

Mon, 28 Oct 2019 17:18:48 +0100

This post was first published at Abilium - Blog.

Recently, we decided to setup a new monitoring service. We opted for the ELK stack. The ELK stack constists of three products:

Elasticsearch - A powerful and flexible search index.
Logstash - Log ingester, filter and forwarder.
Kibana - Dashboard for data visualization.

There exist multiple distros of the ELK stack. One of them is the Open Distro for Elasticsearch by Amazon and another one is the Elastic Stack by Elastic.

We decided to use the Elastic Stack as they provide a collection of Beats in addition. Beats are services that ship all kinds of data (Log, Metrics, Performance, Uptime) to Logstash. It makes it much easier to actually collect data of your services and forward them to Logstash.

At Abilium GmbH Docker and Kubernetes are the default way to run applications. Most times we use Jenkings and Docker Compose to build, test and deploy an application release. But we were not quite happy with docker compose as it does not support a meaningful way to configure the host system. Thus we decided use a very popular automation and configuration management tool: Ansible.

In the following paragraph we will show how you can deploy the Elastic Stack using Ansible and Docker.

Requirements

It’s assumed that you already know how to handle Ansible and are familiar with the related terms. Moreover, we assume that you know the basic idea of Docker and how it interacts with Ansible.

Regarding system requirements for Docker checkout the first section of Install Elasticsearch with Docker

Setup

Ansible in its plain form is a hierarchy of .yml files which tell what task should performed on which machine. There is no final layout when it comes to structuring these files. To get a grasp of what an Ansible project might look like, we printed the folder tree of our example project:

├── ansible.cfg # Global ansible configuration
├── elk-clean.yml # Cleanup playbook
├── elk.yml # Elastic Stack playbook
├── inventory # Inventory folder
│   ├── group_vars # Folder that contains variables grouped by environment
│   │   ├── all # Variables which apply to every environment
│   │   │   ├── vars.yml # Global configuration
│   │   │   └── vault.yml # Ansible Vault secrets
│   │   └── prod # Production environment
│   │       └── vars.yml # Environment specific folder
│   └── hosts.yml # List of hosts grouped by environment
└── roles # Roles are Ansible modules
    ├── clean # Cleanup role that removes all configurations
    │   └── tasks
    │       └── main.yml # Tasks to cleanup containers and related config
    ├── elasticsearch # The Elasticsearch role
    │   └── tasks
    │       └── main.yml  # Tasks to deploy the Elasticsearch Docker container
    ├── kibana # The Kibana role
    │   └── tasks
    │       └── main.yml # Tasks to deploy the Kibana Docker container
    ├── logstash # The Logstash role
    │   ├── handlers
    │   │   └── main.yml # Tasks which are called by other tasks via notifier
    │   ├── tasks
    │   │   └── main.yml # Tasks to deploy the Logstash Docker container
    │   └── templates # Logstash configuration files with Ansible variables
    │       ├── beats.conf
    │       └── syslog.conf
    └── nginx # The nginx module to expose the Kibana dashboard
        ├── handlers
        │   └── main.yml
        ├── tasks
        │   └── main.yml
        └── templates
            ├── nginx-certbot.conf
            └── nginx-ssl.conf

You can replicate this folder tree or checkout the single files in the follow-up sections.

Elasticsearch

This Ansible task file deploys the Elasticsearch Docker container to the target host.

roles/elasticsearch/tasks/main.yml

- name: Create elastic search volume
  docker_volume:
    name: esdata
    driver: local

- name: Start elastic search container
  docker_container:
    name: "{{ elasticsearch_hostname }}"
    image: "{{ elasticsearch_image }}"
    env:
      discovery.type: "single-node"
      ES_JAVA_OPTS: "-Xms512m -Xmx512m"
      xpack.security.enabled: "true"
      xpack.monitoring.collection.enabled: "true"
    volumes:
    - "esdata:/usr/share/elasticsearch/data"
    ulimits:
    - nofile:65535:65535
    networks:
    - name: "{{ network_name }}"
    state: started
    log_driver: "{{ log_driver }}"
    log_options:
      max-size: "{{ log_max_size }}"
      max-file: "{{ log_max_file }}"

- debug:
    msg: >
      Users have to be configured manually. Enable and set the password for the default users with:
      `docker exec -it {{ elasticsearch_hostname }} /bin/bash -c "elasticsearch-setup-passwords auto"`
      Then edit the `vaul.yml` file and copy the password values to the expected variable.

Kibana

Kibana is configured with env variables only.

roles/kibana/tasks/main.yml

- name: Start kibana container
  docker_container:
    name: "{{ kibana_hostname }}"
    image: "{{ kibana_image }}"
    env:
      servername: "{{ server_name }}"
      ELASTICSEARCH_HOSTS: "http://{{ elasticsearch_hostname }}:9200"
      ELASTICSEARCH_USERNAME: "kibana"
      ELASTICSEARCH_PASSWORD: "{{ kibana_password }}"
    networks:
    - name: "{{ network_name }}"
    log_driver: "{{ log_driver }}"
    log_options:
      max-size: "{{ log_max_size }}"
      max-file: "{{ log_max_file }}"

Logstash

Logstash processes data with pipelines. Each pipeline is configured in a .conf file. These files are deployed with Ansible as well. Everytime a file change occurs Ansible will restart the Logstash container.

roles/logstash/tasks/main.yml

- name: Ensure logstash pipeline conf dir exists
  file:
    path: "{{ logstash_conf_dir }}/pipeline"
    state: directory

- name: Copy logstash pipeline conf
  template: src={{ item.src }} dest={{ item.dest }}
  with_items:
    - { src: 'templates/syslog.conf', dest: '/{{ logstash_conf_dir }}/pipeline/syslog.conf' }
    - { src: 'templates/beats.conf', dest: '/{{ logstash_conf_dir }}/pipeline/beats.conf' }
  notify: Restart logstash container

- name: Start logstash container
  docker_container:
    name: "{{ logstash_hostname }}"
    image: "{{ logstash_image }}"
    env:
      XPACK_MONITORING_ELASTICSEARCH_HOSTS: "http://{{ elasticsearch_hostname }}:9200"
      XPACK_MONITORING_ENABLED: "true"
      XPACK_MONITORING_ELASTICSEARCH_USERNAME: "elastic"
      XPACK_MONITORING_ELASTICSEARCH_PASSWORD: "{{ elastic_password }}"
      PATH_CONFIG: ""
    ports:
    - 5000:5000
    - 5044:5044
    volumes:
    - "{{ logstash_conf_dir }}/pipeline:/usr/share/logstash/pipeline:ro"
    networks:
    - name: "{{ network_name }}"
    log_driver: "{{ log_driver }}"
    log_options:
      max-size: "{{ log_max_size }}"
      max-file: "{{ log_max_file }}"

roles/logstash/handlers/main.yml

Handlers are notified by tasks and will be processed at the end of a role deployment.

- name: Restart logstash container
  docker_container:
    name: "{{ logstash_hostname }}"
    restart: true

roles/logstash/templates/beats.conf

The beats pipeline forwards messages sent by Beats services to its appropriate index.

input { stdin { } }

input {
  beats {
    port => 5044
  }
}

output {
  if [@metadata][beat] in ["heartbeat", "metricbeat", "filebeat"] {
    elasticsearch { 
      hosts => ["http://{{ elasticsearch_hostname }}:9200"]
      user => "elastic"
      password => "{{ elastic_password }}"
      index => "%{[@metadata][beat]}-%{[@metadata][version]}"
    }
  }
}

roles/logstash/templates/syslog.conf

The syslog pipeline processes syslog messages using a grok filter.

input { stdin { } }

input {
  tcp {
    port => 5000
    type => syslog
  }
  udp {
    port => 5000
    type => syslog
  }
}

filter {
  if [type] == "syslog" {
    grok {
      match => { "message" => "%{SYSLOG5424PRI}%{NONNEGINT:syslog5424_ver} +(?:%{TIMESTAMP_ISO8601:syslog5424_ts}|-) +(?:%{HOSTNAME:syslog5424_host}|-) +(?:%{NOTSPACE:syslog5424_app}|-) +(?:%{NOTSPACE:syslog5424_proc}|-) +(?:%{WORD:syslog5424_msgid}|-) +(?:%{SYSLOG5424SD:syslog5424_sd}|-|) +%{GREEDYDATA:syslog5424_msg}" }
    }
    syslog_pri { }
    date {
      match => [ "syslog_timestamp", "MMM  d HH:mm:ss", "MMM dd HH:mm:ss" ]
    }
    if !("_grokparsefailure" in [tags]) {
      mutate {
        replace => [ "@source_host", "%{syslog_hostname}" ]
        replace => [ "@message", "%{syslog_message}" ]
      }
    }
    mutate {
      remove_field => [ "syslog_hostname", "syslog_message", "syslog_timestamp" ]
    }
  }
}

output {
  if [type] == "syslog" {
    elasticsearch { 
      hosts => ["http://{{ elasticsearch_hostname }}:9200"]
      user => "elastic"
      password => "{{ elastic_password }}"
      index => "syslog-%{+YYYY.MM.dd}"
    }
  }
}

Nginx

It is easier to setup an Nginx proxy that secures access to the Kibana dashboard than configuring keymaterial for Kibana and setup direct access.

roles/nginx/tasks/main.yml

First this role checks if LetsEncrypt certificates have been generated for the configured domain. If this is not the case it will setup an Nginx instance whose only purpose is to complete the ACME challenge initialized by the Certbot command. Once the certificates have been generated a ssl secured Nginx instance will be deployed.

- name: Ensure nginx conf dir exists
  file:
    path: "{{ nginx_conf_dir }}"
    state: directory

- name: Check if cert files exist
  stat:
    path: "{{ certbot_conf_dir }}/live/{{ server_name }}"
  register: certbot_certs

- name: Copy nginx certbot conf
  template:
    src: templates/nginx-certbot.conf
    dest: "{{ nginx_conf_dir }}/{{ server_name }}.conf"
  when: not certbot_certs.stat.exists

- name: Start nginx container
  docker_container:
    name: ng01
    image: "{{ nginx_image }}"
    ports:
    - 80:80
    volumes:
    - "{{ nginx_conf_dir }}/:/etc/nginx/conf.d/:ro"
    - "{{ certbot_conf_dir }}/:/etc/letsencrypt/"
    - "{{ certbot_conf_dir }}/www/:/var/www/certbot/"
    log_driver: "{{ log_driver }}"
    log_options:
      max-size: "{{ log_max_size }}"
      max-file: "{{ log_max_file }}"
  when: not certbot_certs.stat.exists

- name: Wait for nginx container
  pause:
    seconds: 3
  when: not certbot_certs.stat.exists

- name: Issue certificate with certbot command
  docker_container:
    name: "{{ certbot_hostname }}"
    image: "{{ certbot_image }}"
    volumes:
    - "{{ certbot_conf_dir }}/:/etc/letsencrypt/"
    - "{{ certbot_conf_dir }}/www/:/var/www/certbot/"
    command: certonly --webroot --email {{ certbot_email }} --agree-tos --webroot-path=/var/www/certbot/ -d {{ server_name }}
  when: not certbot_certs.stat.exists

- name: Wait for certificate request
  pause:
    seconds: 3
  when: not certbot_certs.stat.exists

- name: Copy nginx ssl conf
  template:
    src: templates/nginx-ssl.conf
    dest: "{{ nginx_conf_dir }}/{{ server_name }}.conf"
  notify: Restart nginx container

- name: Copy nginx ssl param conf
  copy:
    src: "{{ item }}"
    dest: "{{ certbot_conf_dir }}/"
  with_items:
    - files/options-ssl-nginx.conf
    - files/ssl-dhparams.pem

- name: Start nginx container
  docker_container:
    name: ng01
    image: nginx:1.15-alpine
    ports:
    - 80:80
    - 443:443
    - 9200:9200
    volumes:
    - "{{ nginx_conf_dir }}/:/etc/nginx/conf.d/:ro"
    - "{{ certbot_conf_dir }}/:/etc/letsencrypt/"
    - "{{ certbot_conf_dir }}/www/:/var/www/certbot/"
    networks:
    - name: "{{ network_name }}"
    log_driver: "{{ log_driver }}"
    log_options:
      max-size: "{{ log_max_size }}"
      max-file: "{{ log_max_file }}"

roles/nginx/handlers/main.yml

The Nginx handler for config updates.

- name: Restart nginx container
  docker_container:
    name: ng01
    restart: true

roles/nginx/templates/nginx-certbot.conf

The ACME challenge Nginx config.

server {
    listen 80;
    server_name {{ server_name }};

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    } 
}

roles/nginx/templates/nginx-ssl.conf

The ssl Nginx config that secures access to the Elastic Search API and Kibana dashboard.

server {
    listen 80;
    server_name {{ server_name }};    
    
    location / {
        return 301 https://$host$request_uri;
    }

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    } 
}

# Kibana Dashboard
server {
    listen 443 ssl;
    server_name {{ server_name }};

    ssl_certificate /etc/letsencrypt/live/{{ server_name }}/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/{{ server_name }}/privkey.pem;
    
    location / {
        proxy_pass http://{{ kibana_hostname }}:5601;
    }
}

# Elastic Search
server {
    listen 9200 ssl;
    server_name {{ server_name }};

    ssl_certificate /etc/letsencrypt/live/{{ server_name }}/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/{{ server_name }}/privkey.pem;

    location / {
        proxy_pass http://{{ elasticsearch_hostname }}:9200;
    }
}

Note that cipher suite definitions have been removed from the example. Recommended cipher suites must be obtained by a security consultancy.

Inventory

Ansible works against multiple environments. Therefore configurations and code must be separated. Whereas roles are the code, configurations are the inventory.

inventory/hosts.yml

all:
  hosts:
  children:
    prod:
      hosts: monitoring.example.com
    int:
      hosts: monitoring-int.example.com

inventory/group_vars/all/vars.yml

These variables are set for all environments.

log_driver: "json-file"
log_max_size: "10m"
log_max_file: "3"

They configure the log rotation for the Docker daemon.

inventory/group_vars/all/vault.yml

The vault file stores secrets. It is set for all environments as well. Run the this command to edit the file:

ansible-vault edit inventory/group_vars/all/vault.yml

vault_elastic_password: password
vault_kibana_password: password

These passwords must be updated after the first depoyment.

inventory/group_vars/prod/vars.yml

If you run the Ansible deployment it will use the prod environment definitions by default. The prod environment has been configured with these variables:

server_name: monitoring.example.com
network_name: esnet

nginx_image: nginx:1.15-alpine
nginx_hostname: ng01
nginx_conf_dir: /usr/share/nginx

elasticsearch_image: docker.elastic.co/elasticsearch/elasticsearch:7.4.0
elasticsearch_hostname: es01
elasticsearch_conf_dir: /usr/share/elasticsearch

kibana_image: docker.elastic.co/kibana/kibana:7.3.2
kibana_hostname: ki01

logstash_image: docker.elastic.co/logstash/logstash:7.4.0
logstash_hostname: lo01
logstash_conf_dir: /usr/share/logstash

certbot_image: certbot/certbot
certbot_hostname: cb01
certbot_conf_dir: /usr/share/certbot
certbot_email: info@example.com

elastic_password: "{{ vault_elastic_password }}"
kibana_password: "{{ vault_kibana_password }}"

The hostname is used inside the Docker network.

Playbooks

We are getting closer to the actual Ansible deployment. Ansible playbooks connect hosts, environments and roles. They describe which role must be installed on which host.

elk.yml

This playbook installs the described roles. Note that you can use tags to filter roles for deployments.

---
- hosts: "{{ ehosts | default('prod') }}"
  become: true
  roles:
  - { role: elasticsearch, tags: ["elasticsearch"] }
  - { role: kibana, tags: ["kibana"] }
  - { role: logstash, tags: ["logstash"] }
  - { role: nginx, tags: ["nginx"] }

elk-clean.yml

The cleanup process has been separated from the installation. Cleaning up installed software requires a different order, therefore the cleanup tasks received an exclusive role.

- hosts: "{{ ehosts | default('prod') }}"
  become: true
  roles:
  - clean

Deployment

You have reached the most important section. Here we show what commands can be used to deploy the ELK stack with Ansible and Docker.

Deploy the ELK stack.

ansible-playbook -i inventory elk.yml

Deploy the Logstash role only.

ansible-playbook -i inventory elk.yml --tags logstash

Deploy the Nginx role to localhost.

ansible-playbook -i inventory elk.yml --tags nginx --extra-vars "ehosts=local"

Deploy the Nginx role to localhost with a specified user.

ansible-playbook -i inventory elk.yml --tags nginx --extra-vars "ehosts=local" -u username

Clean the ELK stack.

ansible-playbook -i inventory elk-clean.yml

Clean the Logstash role only.

ansible-playbook -i inventory elk-clean.yml --tags logstash

Demo

Let’s see what a deployment looks like in action:

That’s it! I hope you were able to follow our solution. If not let us know in the comment section.

Notes

As you might noticed there are parts of the Ansible project that have not been solved nicely. F.g. The default users have to be configured manually. We wanna address this points and show how to resolve them if there would be more ressources for engineering.

Problem: Manual setup of default users.
Solution: Create and set the password of the elastic and kibana user automatically with http requests.

Problem: Beat and syslog input services communication is not encrypted. Solution: Encrypt connection to Logstash beat and syslog input with LetsEncrypt certificates.

Problem: Document role variables. Solution: Generate a documentation based on the inventory vars and comments.

Setup GoCD environment using docker

Tue, 06 Nov 2018 12:11:01 +0200

At AdNovum we are running GoCD for automating the continuous delivery (CD) of our software products. GoCD has become the de facto standard for running CD pipelines.

In this post I will give you a short introduction into GoCD using docker. We are going to setup a GoCD environment consisting of a server, an agent and deployable material. Further we are going to configure a deployment pipeline and build an node.js application.

GoCD environment

The GoCD server provides an interface for configuring pipelines, environments and agents. The agent does the actual work if a deployment pipeline is triggered. Workload is managed by the GoCD server and shared among multiple agents.

In order setup our GoCD environment you need to install docker.

If docker is available, start by downloading the official GoCD server image.

docker pull gocd/gocd-server:v18.10.0

Next start a new GoCD server container.

docker run -d --name gocd-server -p8153:8153 -p8154:8154 gocd/gocd-server:v18.10.0

In your browser open https://localhost:8154. In this interface you can manage the GoCD server.

In order to run a pipeline we need a GoCD agent.

Pull the official GoCD alpine image.

docker pull gocd/gocd-agent-alpine-3.8:v18.10.0

Run the command below to start a new GoCD agent container.

docker run -itd --name gocd-agent -e CI=true -e GO_SERVER_URL=https://$(docker inspect --format='{{(index (index .NetworkSettings.IPAddress))}}' gocd-server):8154/go gocd/gocd-agent-alpine-3.8:v18.10.0

Make sure that server and agent have successfully been started.

docker ps

The agent is registering itself ùsing the GO_SERVER_URL variable and should be listed in the management interface https://localhost:8154/go/agents#!/agentState/asc/.

If the GoCD agent entered the state pending, select it and click on Enable.

Agent configuration

Materials are the input for a build pipeline in GoCD. A material can be anything, an svn repo, folder, file or as in most cases a git repo. We are going to use the gocd-node-example app as our material.

Building the application requires two binaries:

yarn
node

These binaries are not installed on the image by default, so we need to update the image.

Log into the gocd-agent container.

docker exec -it gocd-agent bash

Install the binaries using the alpine package manager.

apk add --no-cache nodejs yarn

Logout and update the container image.

docker stop gocd-agent
docker commit gocd-agent gocd-node-agent
docker start gocd-agent
docker images

The commited image should be listed. If you spin up a GoCD agent again, use the new image.

Pipeline configuration

Now we are ready to configure and run a GoCD pipeline.

In the management interface create a new pipeline with the name gocd-node-example.

Select Git as material type and enter this url: https://codeberg.org/janikvonrotz/gocd-node-material.git

A pipeline passes a material and its resulting artifacts through multiple stages. Each stage performs a build procedure or performs checks on the artifact. Here is an example of a 4-stage pipeline:

build
test
analyze
publish

We are going to have configure a build stage with two tasks and a test stage with one task.

Name the current stage build and the job name build.

Select More… as task type and enter /bin/bash in the command field.

In the argument field add:

-c
yarn

Finish the wizard and open the tab Stages.

Select the build stage, then the build job and add a new task.

task type: More…
command: /bin/bash
argument:

-c
yarn build

Add one more stage with the following details:

stage name: test
job name: test
task type: More…
command: /bin/bash
argument:

-c
yarn test

Once all stages have been created, unpause and run the pipeline.

![gocd pipeline in progress](/images/gocd pipeline in progress.PNG)

GoCD will poll the master branch for changes. Whenver a change is committed GoCD will trigger the pipeline.

Troubleshooting

proxy settings

In case the docker host runs behind a proxy and GoCD cannot connect to the git repository, make sure to set the git config proxy withing the docker container.

docker exec -it _CONTAINER_NAME_ bash
su go
git config --global http.proxy https://_PROXY_HOST_:_PROXY_PORT_
git config --global https.proxy HTTP_PROXY=http://_PROXY_HOST_:_PROXY_PORT_

For other outbound connection you can also pass the proxy env vars via docker.

docker run -e HTTPS_PROXY=https://_PROXY_HOST_:_PROXY_PORT_ -e HTTP_PROXY=http://_PROXY_HOST_:_PROXY_PORT_ ...

github connection refused

If you cannot connect with the github repository and get this fatal error:

fatal: unable to access 'https://codeberg.org/janikvonrotz/gocd-node-material.git/': Failed to connect to github.com port 443: Connection refused

It is most likely a proxy related problem.

wrong version number

Assuming the proxy env vars have been and you get this error:

STDERR: fatal: unable to access 'https://codeberg.org/janikvonrotz/gocd-node-material.git/': error:1400410B:SSL routines:CONNECT_CR_SRVR_HELLO:wrong version number

Make sure to set the git proxy config for the go user:

docker exec -it _CONTAINER_NAME_ bash
su go
git config --global http.proxy https://_PROXY_HOST_:_PROXY_PORT_
git config --global https.proxy HTTP_PROXY=http://_PROXY_HOST_:_PROXY_PORT_

GoCD agent pending

If the GoCD agent entered the state pending, select it and click on Enable.

yarn install job fails

Assuming the following error occurs during the install stage:

...
[1/4] Resolving packages...
info If you think this is a bug, please open a bug report with the information provided in "/godata/pipelines/build/yarn-error.log".
...

You need to set the yarn proxy settings in the gocd-agent container.

yarn config set proxy http://_PROXY_HOST_:_PROXY_PORT_
yarn config set https-proxy https://_PROXY_HOST_:_PROXY_PORT_

Zabbix stack with Vagrant, CoreOS and Docker

Thu, 08 Oct 2015 16:03:44 +0000

This short guide shows you how to set up a virtual Zabbix Network Monitoring Stack with MySQL and CoreOS deployed by Docker.

On your host machine make sure that these tools are available.

First we are going to setup a virtual machine with Vagrant.

Create a project directory and open navigate there with your command line. Next clone the CoreOS Vagrant repository.

git clone https://github.com/coreos/coreos-vagrant/
cd coreos-vagrant

This repository is preconfigured CoreOS installation.

Open up the Vagrant file and edit the lines as showed below.

$vm_memory = 2024

Now install and run the virtual machine with Vagrant.

vagrant up

If this command finishes without an error, your virtual machine should be up and running in the VirtualBox environment.

Now connect to the virtual machine with ssh.

vagrant ssh

Hint: For windows hosts, make sure that the ssh.exe binary that is shipped with Git is available in your system PATH variable.

CoreOS has Docker pre-installed, so no worry about that. We will now deploy our MySQL and Zabbix stack with preconfigured Docker images.

Install and run the MySQL with Docker.

docker run --name mysql -p 3306:3306 -e MYSQL_ROOT_PASSWORD=password -d mysql:latest

Install and the phpMyAdmin image.

docker run -d --name phpmyadmin --link mysql:mysql -p 1234:80 nazarpc/phpmyadmin

Get the configuration of your MySQL container.

docker inspect mysql

And look for the IPv4 address. We will use in the next statement.

Run the Zabbix image

docker run \
-d \
--name zabbix \
-p 80:80 \
-p 10051:10051 \
-link mysql:db \
--env="DB_USER=root" \
--env="DB_PASS=password" \
--env="SLACK_WEBHOOK=webhook_url" \
million12/zabbix-server

Now open the browser on your host machine to http://host_ip and login with Admin:zabbix.

You can get the host machines ip by tipping ifconfig on command line.

You phpMyAdmin installation is accessbile under http://host_ip:1234.

Troubleshooting

In case some fails are doesn’t work as supposed, follow these steps:

Reboot your virtual machine.

sudo reboot

docker start container_name

Check if the containers have been started successfully.

docker ps

Source

https://hub.docker.com/r/million12/zabbix-server/