New Meetup – Vagrant from scratch to LAMP stack

Automated IT Solutions are running a new Meetup in Edinburgh on Friday 18th May, check out the details and register for this free session here – beer, pizza and free HashiCorp stickers included!:

Vagrant from scratch to LAMP stack

Friday, May 18, 2018, 6:15 PM

HAYS
7 Castle St, Edinburgh EH2 3AH Edinburgh, GB

18 Members Attending

Automated IT Solutions are presenting a session on HashiCorp Vagrant: “from scratch to LAMP stack” by Adam Cheney. In this session you will learn: – Vagrant basics, introduction and usage – How to install and configure Vagrant – Provisioning VMs with Vagrant and Ansible followed by a live demonstration/workshop of building a LAMP stack within Vagra…

Check out this Meetup →

Spalted Beech bowl – green woodturning

The weather’s finally warm enough for me to do some woodturning again.

I’ve been wanting to make some more “green” Beech bowls from the trees I chopped up early last year. Here are pics of the process.

chainsawed a “50p” shaped bowl blank from a slab of wood that’s been sitting in the shed:

quickly and easily made round – green wood cuts very easily, and smells good too!

spinning at about 2,000 rpm:really nice spalting all the way through: some homemade beeswax and oil applied, with help from a bit of heat: inside done too… and the underneath finished in the reversing jaws: all done – will try and let it finish drying out slowly to avoid serious cracking, but it’s bound to warp a fair bit…

Adding an insecure-registry to Docker on Ubuntu

Quick note on adding –insecure-registry 172.30.0.0/16 to docker running on Ubuntu.

While trying to get oc cluster up working on an Ubuntu VM I was getting the following error message and (helpfully) a suggested solution:

don@ubuntu:~# oc cluster up doncluster
Starting OpenShift using registry.access.redhat.com/openshift3/ose:v3.7.23 …
— Checking OpenShift client … OK
— Checking Docker client … OK
— Checking Docker version … OK
— Checking for existing OpenShift container … OK
— Checking for registry.access.redhat.com/openshift3/ose:v3.7.23 image … OK
— Checking Docker daemon configuration … FAIL
   Error: did not detect an –insecure-registry argument on the Docker daemon
   Solution:
     Ensure that the Docker daemon is running with the following argument:
         –insecure-registry 172.30.0.0/16

I normally work on RedHat boxes, and this is usually easily solved by going to /etc/sysconfig/docker and adding the desired registry to the list of “INSECURE_REGISTRY=” line.

On more recent RedHat docker installs this is now done in the externalised config file /etc/containers/registries.conf.

On my Ubuntu VM neither of these exist, and running locate with grep plus a quick google brings back loads of other file locations and suggestions, none of which worked for me (/etc/default/docker, exporting DOCKER_OPTS etc etc).

So, I checked systemctl status docker and got the following:

don@ubuntu:~# systemctl status docker
● docker.service – Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2018-01-24 11:29:25 GMT; 25min ago
Docs: https://docs.docker.com
Main PID: 4648 (dockerd)
Tasks: 19 (limit: 19660)
Memory: 26.8M
CPU: 1.324s
CGroup: /system.slice/docker.service
├─4648 /usr/bin/dockerd -H fd:// –insecure-registry 172.30.0.0/16
└─4667 docker-containerd -l unix:///var/run/docker/libcontainerd/docker-containerd.sock –shim docker-containerd-shim –metrics-interval=0 –start-timeout 2m –state-di (…snip)

which prompted me to look at the file /lib/systemd/system/docker.service

Adding the settings I wanted to the end of the ExecStart line like so:

ExecStart=/usr/bin/dockerd -H fd:// –insecure-registry 172.30.0.0/16

followed by a

systemctl daemon-reload
systemctl restart docker

did the trick, finally.

I am now hitting this issue, which looks like a systemd + docker mismatch… and am thinking CentOS may be a better place to test this!

don@ubuntu:~# oc cluster up doncluster
Starting OpenShift using registry.access.redhat.com/openshift3/ose:v3.7.23 …
— Checking OpenShift client … OK
— Checking Docker client … OK
— Checking Docker version … OK
— Checking for existing OpenShift container … OK
— Checking for registry.access.redhat.com/openshift3/ose:v3.7.23 image … OK
— Checking Docker daemon configuration … OK
— Checking for available ports … FAIL
   Error: Cannot get TCP port information from Kubernetes host
   Caused By:
     Error: cannot start container cec56a101a46aa25adb6806f7c84df218e5d79c392fa0c38207f92510eb46538
     Caused By:
       Error: Error response from daemon: {“message”:”oci runtime error: rootfs_linux.go:53: mounting \”/sys/fs/cgroup\” to rootfs \”/var/lib/docker/aufs/mnt/aeedaa83596edc9cb2b2cd835000277f9a5355f709694f8ec70d88787395cbd0\” caused \”no subsystem for mount\””}

argh.

Getting started with Terraform and AWS

These are my notes from running through the Terraform getting started guide here:

https://www.terraform.io/intro/getting-started/install.html

to set up terraform (on a Mac) and provision a basic test instance in AWS.

Install process

This is very easy, simply download terraform for your platform (a single binary), extract it somewhere sensible and add that location to your PATH variable.

I set this up in my .profile, along the lines of:

export TFORM=/Users/donaldsimpson/TFORM
export PATH=$M2:$TFORM:$PATH

quick check that all looks ok:

Setup

As per the guide, the next steps are to get a note of your AWS access_key and secret_key from this AWS page, then create and edit a local “example.tf” file for your project, like this:

provider "aws" {
  access_key = "ACCESS_KEY_HERE"
  secret_key = "SECRET_KEY_HERE"
  region     = "us-east-1"
}

resource "aws_instance" "example" {
  ami           = "ami-2757f631"
  instance_type = "t2.micro"
}

I hit this issue: https://github.com/hashicorp/terraform/issues/4367 as my AWS account is pretty old, and had to change the values for

ami = "ami-2757f631"
instance_type = "t2.micro"

to be:

ami = "ami-408c7f28"
instance_type = "t1.micro"

Terraform init

You should now be able to run terraform init and see something positive…

Check the plan

Running “terraform plan” provides a dry run/sanity check of what would be done

Make it so

terraform apply: run the plan, and actually create the resources listed above:

Show it is so

Once that has completed, you can check your AWS console and see the newly created instance:

“terraform show” can confirm the same details in a less pointy-clickety way:

Next steps

This was all pretty simple, quick and straightforward.

The next steps are to manage the hosts in an Infrastructure as Code manner, adding in changes and deletions/reprovisioning, and to do something useful with them.

I’d also like to try using Terraform with Digital Ocean and VMWare providers.

 

Jenkins and Docker – Part 1 of 3

This post is the first in a series of 3 introducing the combined power of Jenkins, Docker, and the Jenkins DSL.

They should hopefully provide enough information to get to grips with both Docker and Jenkins – what they both do and how to use them – by showing some practical examples of them working together.

The first step, if you haven’t already, is to download and install Docker on your platform – the Docker website covers this in good detail for most platforms…

Docker for Mac

Docker for Windows

Docker for Linux

Once that’s done, you can try it out with the customary “Hello World” example…

I’m running Docker on an Ubuntu VM, but the commands and the results are the same regardless of platform – that’s one of the main Docker concepts.

You can then check which processes (docker containers) are running using the “docker ps” command – in my example you can see that there’s one Jenkins image running. If you run “docker ps -a” you will see all containers (including stopped ones, of which I have a few on this host):

and you can check your Docker version with:

root@ubuntud:~# docker --version
Docker version 1.13.0, build 49bf474

Now that the basic setup is done, we can move on to something a little more interesting – downloading and running a “Dockerised” Jenkins container.

I’m going to use my own Dockerised Jenkins Image, and there will be more detail on that in the next post – you’re welcome to try it out too, just run this command in your terminal:

docker run -d -p 8080:8080 donaldsimpson/dockerjenkins

if you don’t happen to have my docker image cached locally (like I do) then docker will automatically download it for you from Docker Hub then run it:

That command did a quite few important things, here’s a quick explanation of them all:

docker run -d

tells docker that we want to run the container in the background so that we can carry on and do other things while it runs. The alternative is -it, for an interactive/foreground session.

docker run -d -p 8080:8080

The -p 8080:8080 tells docker to map port 8080 on the local host to port 8080 in the running container. This means that when we visit localhost:8080 the request will be passed through to the container.

docker run -d -p 8080:8080 donaldsimpson/dockerjenkins

and finally, we have the namespace and name of the Docker image we want to run – my “donaldsimpson/dockerjenkins” one – more on this later!

You can now visit port 8080 on your Docker host and see that Jenkins is up and running….

 

That’s Jenkins up and running and being happily served from the Docker container that was just pulled from Docker Hub – how easy was that?!

And the best thing is, it’s entirely and reliably repeatable, it’s guaranteed to work the same on all platforms that can run Docker, and you can quickly and easily update, delete, replace, change or share it with others! Ok, that’s more than one thing, but the point is that there’s a lot to like here 🙂

That’s it for this post – in the next one we will look in to the various elements that came together to make this work – the code and configuration files in my Git repo, the automated build process on Docker Hub that builds and updates the Docker Image, and how the two are related.