As part of a story in a recent development iteration at work, I found myself guiding two development teams in the use of Docker Hub.
Strangely my current project had already had an indirect dependency on Docker Hub for a few months, but today was the first time that we actually needed to consider the ins and outs of this particular system.
In this case the "in" side involves our continuous deployment system pushing an image, and the "out"side involves a separate system pulling an image from the same repository.
In the interests of ensuring that each project team does not run the risk of accidentally blowing away anything or everything that the other project teams have set up, I took it upon myself to learn the ins and outs of group permissions in Docker Hub.
Now instead of just having one big group of Owner users associated with our organisation we have two additional groups for my current project - one that contains users with the right to push images, and one with the right to read (pull) images.
Wednesday, 12 November 2014
Monday, 10 November 2014
Strange day in the office
My plan to wait for other teams to sort out the approach to deploying applications in Docker didn't work out quite the way I had hoped.
This morning I guided some colleagues to get our application set up to run from a Docker image, without worrying about the details of deploying anywhere - expecting that another development team would have that sorted out from their project first.
Sure enough, come mid-afternoon we'd established that the other development team didn't need that functionality yet so we'd have to figure it out for ourselves.
Okay, we have a tools engineering team that have already provided something Dockerised automagically through Dockerhub so they'll be able to show us how to do it in no time.
It turned out that the approach used so far involved Dockerhub pulling the Docker image content directly from a Git repository. This doesn't quite suit our needs, as our application needs to be built from source first.
The ugly option involved setting up a dedicated Git repository for our binary artifact, which Dockerhub could pull across.
Back to the drawing board.
An hour or so later I overheard my colleagues mentioning something about authenticating to Dockerhub from Gradle. It turns out that the plugin they've used for creating a Docker image can also be applied to push to a Docker repository.
Don't worry, there's more fun ahead to get this set up in the continuous deployment pipeline.
This morning I guided some colleagues to get our application set up to run from a Docker image, without worrying about the details of deploying anywhere - expecting that another development team would have that sorted out from their project first.
Sure enough, come mid-afternoon we'd established that the other development team didn't need that functionality yet so we'd have to figure it out for ourselves.
Okay, we have a tools engineering team that have already provided something Dockerised automagically through Dockerhub so they'll be able to show us how to do it in no time.
It turned out that the approach used so far involved Dockerhub pulling the Docker image content directly from a Git repository. This doesn't quite suit our needs, as our application needs to be built from source first.
The ugly option involved setting up a dedicated Git repository for our binary artifact, which Dockerhub could pull across.
Back to the drawing board.
An hour or so later I overheard my colleagues mentioning something about authenticating to Dockerhub from Gradle. It turns out that the plugin they've used for creating a Docker image can also be applied to push to a Docker repository.
Don't worry, there's more fun ahead to get this set up in the continuous deployment pipeline.
Subscribe to:
Posts (Atom)