Request: Docker Registry

[danieldn]

Summary

See resource request https://docs.google.com/document/d/1GCn1Egja-BcLiynhOPMafNPKd0et96GZOvuxIIB5G7c/edit#

Impact

Resource request

Tasks

• [x] Create Docker Hub account for hackoregon
• [ ] Configure as necessary
• [ ] Document

Definition of Done

Hacko developers should be able to push and pull images to registry

[danieldn]

Update: @MikeTheCanuck emailed Docker to recover Hackoregon namespace on Docker Hub. Likely will go through (do not surrender mike!)

[MikeTheCanuck]

cf. there's an existing Docker user named hackoregon that some well-meaning soul created back in the dark days of 2016: https://hub.docker.com/u/hackoregon

[MikeTheCanuck]

And we now have access to the "Hackoregoncivic" organization on Docker Hub: https://cloud.docker.com/orgs/hackoregoncivic/teams?page=1&page_size=10

@danieldn has been granted Owners access here so we now have two active Hacko'ers who can help manage this

[MikeTheCanuck]

Q for @BrianHGrant - under what well-known, durable name should we create a repo? e.g.

• "cookiecutter" sounds a bit generic - "Django-cookiecutter" would be more semantically descriptive but probably could be improved upon
• "backend-Docker-2019" sounds a bit too time-specific - "backend-Docker-Django-template" would be more semantically descriptive but possibly too much of a mouthful

How many containers are we expecting to publish to start? That's the number of Docker hub repos we'll need.

[bhgrant8]

@MikeTheCanuck , I agree getting away from time semantic naming conventions is good, as time can be part of our versioning.

As we are now including "hackoregoncivic" in namespace, is "backend-docker" enough?

We can do "backend-docker-django" vs. "backend-docker-node" or something like that, not sure if "template" would really be necessary.

When folks pull the image, it will be "docker pull hackoregoncivic/backend-docker-django:(version or latest)" or included in docker-compose, or what have you. But this should give semantic understanding of what image you are pulling.

With the cookiecutter/application template repo, trying to balance python standards + our org, will open an issue related to this, but it will not have it's own docker image in a dockerhub repo.

Based on conversation with data science lead (Karen Ng) I know of 2 docker images:

• data science image (https://cloud.docker.com/repository/docker/karenngcivicsoftware/hackordatasciencetemplate)
• backend "golden image" repo

both based in python but datascience is conda env, backend is django/web app

[bhgrant8]

For backend, let's qualify the above with a development repo and production repo:

backend-docker-django-dev
backend-docker-django

Development as in development of the docker image itself, vs. development API project.

[bhgrant8]

adding @karenng-civicsoftware

[MikeTheCanuck]

Alright, let's see what's needed to make this scheme operational. I've created the first repo hackoregoncivic/backend-docker-django-dev in our hackoregoncivic Docker Hub org. It reports this approach to push a new image to the repo:

docker tag local-image:tagname reponame:tagname
docker push reponame:tagname

I can a few necessary next steps ahead of us:

• authentication - @bhgrant8 do you have a Docker Hub account we can add to the Hub Org's maintainers group? And does anyone know what is the usual methodology for authenticating a docker push command to Docker Hub from Travis?
• GitHub repo linking - what repo do we link this to?
• integration to the 2019 API projects' build

[bhgrant8]

• authentication - @MikeTheCanuck, my docker hub account is:bhgrant.
• See guide here regarding auth for travis push to docker hub: https://docs.travis-ci.com/user/docker/#pushing-a-docker-image-to-a-registry but basically will need to set "DOCKER_USERNAME" and "DOCKER_PASSWORD", so we may want to create a "deployer" profile or something like that in docker?
• repo linking - we are working on this repo: https://github.com/hackoregon/2019-backend-docker

Thanks!

[bhgrant8]

Backend is successfully deploying docker image to hackoregoncivic repo, using the deployer credentials: https://github.com/hackoregon/2019-backend-docker/tree/staging and this repo: https://cloud.docker.com/u/hackoregoncivic/repository/docker/hackoregoncivic/backend-docker-django-dev

will deploy to master, once we confirm any outstanding issues.

using travis: https://github.com/hackoregon/2019-backend-docker/blob/staging/.travis.yml

and docker-deploy script: https://github.com/hackoregon/2019-backend-docker/blob/staging/bin/docker-deploy.sh

which does a branch based deploy to a staging repo, to be able to pull from repo and test a project, prior to deploying master image which will go to a non -dev tagged repo. All developers will use the non-dev tagged repo for both development and production

we will not link repo in dockerhub, as we are using travis to deploy vs. the docker "autobuild"

integration to 2019 projects will come via DOCKERFILE in the cookiecutter repo:

https://github.com/hackoregon/2019-backend-cookiecutter-django/blob/test-docker/%7B%7Bcookiecutter.github_repo%7D%7D/DOCKERFILE

generally this maybe complete?

[nam20485]

Apparently GitHub has a Docker registry now: https://github.com/features/package-registry.

Or at least will soon.

Using this option may ease the authentication method.