chmod 600 and helping Bitcoin miners

I have just completed my second pass through The Docker Book.  Running through it again was a good decision.  I flew through it this time and surprised myself at how much I have learnt.

I even learnt what happens when you run the command ‘chmod 600’ on it’s own (a cut and paste error).  Even that turned out to be a positive learning experience as it pushed me down the route (or root haha) of using AWS snapshots and volumes for real to resolve the issue.

This time around I noticed the following text which escaped my attention first time:

The significance of this was not lost on me.  First time around I completed the Docker API chapter and being short of time left the “authenticate your API” chapter until a few days later.  When I came back to it, imagine my surprise at seeing Bitcoin mining containers happily whirring away on my host.

In both of these examples I realised that learning by your mistakes is a powerful learning tool, particularly as I am using my own AWS hosts.  Clearly either of these mistakes would have been disastrous in a real life production context.  This time around I was very thorough in only opening up as much access as was needed rather than having everything open to the world.

So what next?  I had been planning to Dockerise Riemann for the Art of Monitoring book.  I will get to that, but feel the need to branch out a bit even if Docker still plays a part.  Current thinking is to study and play with:

  • MongoDB
  • Git (I am embarrassed by how little I use it)
  • Kubernetes (really excited about this)

I am also going to try and organise my reading a little so am planning to tackle the following:

  • The DevOps Handbook
  • Sam Newman’s Microservices
  • Google SRE
  • The Lean Enterprise

Some choices there are influenced by a possible change of role – which will be a good step towards something more DevOpsy (sorry) – for which I am going to have to know my stuff.  I hope re-reading the first two will be as rewarding as a second pass through The Docker Book.

To further assist my mission, I have set myself the objective of watching a webinar each week. I am amazed at how much great material is out there.

My Picks

Finally, I liked the Food Fight’s Picks” so much, I am going to borrow it.  My first one in homage to Food Fight is one of their very own podcasts on the Netflix OSS.  This is a few years old (2013) but I enjoyed it immensely.  Find it here..

A forest in a bottle in a spaceship in a maze

The title of this post is one of my favourite quotes from one of my favourite episodes of my favourite shows.  See the foot of this post for more info.

I was reminded of this quote whilst tackling chapter five of The Docker Book.  I cannot recall finishing this section last time around as I was running Docker on my Mac, not an EC2 instance running Ubuntu as I am now.   I ran into limitations on the Mac Docker implementation.

When I had completed the section I had (deep breath), Jenkins running in a Docker container on an EC2 instance, creating Docker containers to run Ruby apps.  I connected to the EC2 instance from iTerm running on my Mac.

I am particularly proud of completing this one as I ran into a number of issues through which I logically debugged to fix.  I learnt  a lot as I did so but even better I was using tools, techniques, knowledge and logic that would have been beyond me first time around.

What I am not particularly proud of is that I managed to lose a Dockerfile that had an issue so could not compare it to the Dockerfile that ultimately worked – opportunity lost there to learn something else.  However, I know the area where the issue occurred so all is not lost.

If you want to know more about forests, bottles, rockets and mazes, visit here.

 

Docker vs Kubernetes vs Mojo

I have been making some good progress on my second run through of The Docker Book. I am definitely learning different things this time around. I have just completed the chapter on using Docker to make the testing of a web page easier – spinning up containers with different web technologies to test a simple page. I am now running through the chapter on doing something similar with a web application.

Confession time, I lost a little motivation over the past couple of weeks.  Not sure why but possibly a bit of tiredness, work being tough and everyone going back to the school routine.  Feel like my mojo has come back a bit in recent days though.

Despite my fun with Docker, more than one person I know has been hinting that Kubernetes has been “winning the war”.  In general, I think it would be a good idea to get stuck into a few specific technology areas next.  For a while I have been planning to run through Mongodb tutorials and my Git knowledge is not great so that needs some TLC too.  I will add Kubernetes to the list but there does not seem to be as many decent books and tutorials as for Docker.

Finally, I have produced the following Dockerfile whilst running through basic Docker commands.

# comment
# practising Docker commands
FROM ubuntu:16.04
MAINTAINER richardx14 "richard@blueharvest.co.uk"
#RUN apt-get update; apt-get install -y nginx
#RUN echo 'container!' > /var/www/html/index.html
#EXPOSE 80
#
# CMD when container has been launched. If you use a command after docker run, it overrides this
CMD ["/bin/bash"]
#
# ENTRYPOINT - any params used after docker run get passed as params to the ENTRYPOINT. Similar to CMD
# WORKDIR - cd
WORKDIR /var/log
#
# ENV env variables. Persisted into containers that are launched from image
ENV RICHARD richard
#
# USER account, UID, group that containers run from the image will be run by
#
# VOLUME - adds volumes to containers created from image. Allows access to the containers volumes
VOLUME ["/var/log"]
#
# ADD adds from build env into image
ADD testaddfile /var/log/testaddfile
#
# COPY add without without decompression. Will create missing directories
COPY testaddfile /var/log/copyoftestaddfile
COPY testaddfile /test/add/file/testaddfile
#
# LABEL - add metadata
LABEL name="Richard's test label"
#
# ARG - pass build time variables, can set default. use --build-arg build=buildnumber
ARG build
ARG builduser=user
#
# SHELL can override default shell
#
# HEALTHCHECK
HEALTHCHECK --interval=60s --timeout=1m --retries=5 CMD curl http://www.google.co.uk || exit 1
#
# ONBUILD triggered when image is used as the basis for another image
ONBUILD LABEL name="Richard's test label ONBUILD"