Some pics of a (mostly) beech bird feeding house I made a while back – the first pic shows one of many visits from the local Woodpeckers captured on my CCTV camera.
Beech House
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!:
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…
Snowtastic
Adding an insecure-registry to Docker on Ubuntu
Quick note on adding an entry like –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 line:
INSECURE_REGISTRY=
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.
Defender 90
Recent woodturnings
Some pics of wooden things I’ve made recently…
Little pot with scorched edges:
Small oak bowl:
Deep Ash (I think? maybe Beech?) bowl with cool grain and spalting:
My first attempt at Pyrography, on a little Celtic vase sort of thing:
Hand turned natural-edge wooden bowls
Some pics of my first attempts at turning “natural edge” wooden bowls
These were made from a very nice chunk of Rowan wood I was kindly given a while back
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…
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.