Posts

Posted on

Docker typical workflow (rough notes)

I’m still scratching the surface getting up to speed with Docker, but here’s some rough notes for what seems to be a typical development workflow.

Build an image (from Dockerfile):

docker build -t imagename .

Run an image (create a container):

docker run -d -p port:port imagename

 

If pushing an image to a local Registry to share to other machines:

Tag an image:

docker tag imagename ip-of-registry:port/imagename

Push image to registry:

docker push ip-of-registry:port/imagename

For my other notes and experiences in Dockerland so far, see here.

Posted on

Running a local insecure Docker Registry for testing

To start and run a local Repository for sharing images between machines (from here):

docker run -d -p 5000:5000 --restart=always --name registry registry:2

To tag a local image and push it into your repository:

docker tag imagename [ip of your docker machine]:5000/imagename

And then push it into your repo:

docker push [ip of your docker machine]:5000/imagename

By default, the docker client fails when attempting to push an image to a locally running registry if you haven’t configured TLS and certificates. If you’re running a registry locally for testing, you can configure the local client to trust an insecure Registry by:

  • docker-machine ssh [name of docker machine]
  • sudo vi /var/lib/boot2docker/profile
  • Add this line to the EXTRA_ARGS var:
--insecure-registry=[ip of your docker machine]:5000

This tip from this article.

Update1: if running on Linux (no docker-machine), add the above property to /etc/default/docker and then

sudo service docker restart

Update2: if docker is running as a service using systemd (e.g. the Hypriot Raspberry Pi image), you need to edit

/etc/systemd/system/docker.service

… append the –insecure-registry option to the end of the line that starts: ExecStart (further details here)

Now trying the push again, and success!

$ docker push 192.168.99.100:5000/spring-boot-rest-alpine

The push refers to a repository [192.168.99.100:5000/spring-boot-rest-alpine]

d5a685774b12: Pushed 

726baddb2cde: Pushed 

bb81ee534db3: Pushed 

77f08abee8bf: Pushed 

latest: digest: sha256:cafa45a64cf25533a1544f37ef7ee3fac614cb2a8d8be30efe9b3c84cebabc52 size: 1159
Posted on

Managing Docker containers with Shipyard

There’s plenty of things that amaze me about Docker, but one of the things I find interesting is the number of available images with all sorts of stuff preconfigured and ready to spin up, including Docker management related tools like Shipyard that also run within Docker containers themselves.

Installing couldn’t be simpler, just pull down a script and run it, and it pulls down a number of images and spins them up:

curl -sSL https://shipyard-project.com/deploy | bash -s

Within a few seconds Shipyard is up and running, and after logging on, you get the snappy looking dashboard:

Now, off to do a bit more studying to configure a spin up a Swarm cluster 🙂

Posted on

Lightweight docker images for Java apps

There’s a number of posts (e.g. here) talking about the official Java docker images being on the large side – in Docker terms, the standard images at > 600MB before you even build your image containing you app are … pretty big.

Suggestions are to use a smaller image as a starting point, like Alpine Linux. It looks like at some point the official Java images have been updates to include a number of Alpine based images too.

Pulling down an OpenJDK 8 image, java:openjdk-8-jdk and then java:openjdk-8-alpine, there’s a massive size difference between the size of the two:

If you’re planning on running something lightweight like a Spring Boot app, looks like the provided Alpine images are a good starting point.

Proudly powered by WordPress