github – Docker https://www.docker.com Fri, 10 Feb 2023 19:16:33 +0000 en-US hourly 1 https://wordpress.org/?v=6.2.2 https://www.docker.com/wp-content/uploads/2023/04/cropped-Docker-favicon-32x32.png github – Docker https://www.docker.com 32 32 Docker V2 Github Action is Now GA https://www.docker.com/blog/docker-v2-github-action-is-now-ga/ Tue, 27 Oct 2020 15:54:28 +0000 https://www.docker.com/blog/?p=27148 Docker is happy to announce the GA of our V2 Github Action. We’ve been working with @crazy-max over the last few months along with getting feedback from the wider community on how we can improve our existing Github Action. We have now moved from our single action to a clearer division and advanced set of options that not only allow you to just build & push but also support features like multiple architectures and build cache.

The big change with the advent of our V2 action is also the expansion of the number of actions that Docker is providing on Github. This more modular approach and the power of Github Actions has allowed us to make the minimal UX changes to the original action and add a lot more functionality.

docker v2 github action

We still have our more meta build/push action which does not actually require all of these preconfiguration steps and can still be used to deliver the same workflow we had with the previous workflow! To Upgrade the only changes are that we have split out the login to a new step and also now have a step to setup our builder. 

  -
        name: Setup Docker Buildx
        uses: docker/setup-buildx-action@v1

This step is setting up our builder, this is the tool we are going to use to build our Docker image. 

This means our full Github Action is now: 

name: ci
 
on:
 push:
   branches: main
 
jobs:
 main:
   runs-on: ubuntu-latest
   steps:
     -
       name: Setup Docker Buildx
       uses: docker/setup-buildx-action@v1
     -
       name: Login to DockerHub
       uses: docker/login-action@v1
       with:
         username: ${{ secrets.DOCKERHUB_USERNAME }}
         password: ${{ secrets.DOCKERHUB_TOKEN }}
     -
       name: Build and push
       id: docker_build
       uses: docker/build-push-action@v2
       with:
         push: true
         tags: bengotch/samplepython:latest

Let’s now look at some of the more advanced features we have unlocked by adding in this step and the new QEMU option.

Multi platform

By making use of BuildKit we now have access to multi-architecture builds, this allows us to build images targeted at more than one platform and also build Arm images.

To do this, we will need to add in our QEMU step: 

       name: Set up QEMU
       uses: docker/setup-qemu-action@v1

And then within our build & push step we will need to specify out platform to use: 

-
       name: Build and push
       uses: docker/build-push-action@v2
       with:
         context: .
         file: ./Dockerfile
         platforms: linux/386,linux/amd64,linux/arm/v6,linux/arm/v7,linux/arm64,linux/ppc64le,linux/s390x
         push: true
         tags: |
           bengotch/app:latest

Cache Registry 

To make use of caching to speed up my builds I can now make use of the 

name: ci
 
on:
 push:
   branches: master
 
jobs:
 registry-cache:
   runs-on: ubuntu-latest
   steps:
     -
       name: Set up Docker Buildx
       uses: docker/setup-buildx-action@v1
     -
       name: Login to DockerHub
       uses: docker/login-action@v1
       with:
         username: ${{ secrets.DOCKERHUB_USERNAME }}
         password: ${{ secrets.DOCKERHUB_TOKEN }}
     -
       name: Build and push
       uses: docker/build-push-action@v2
       with:
         push: true
         tags: user/app:latest
         cache-from: type=registry,ref=user/app:latest
         cache-to: type=inline

To see more examples of the best practices for using our latest version of the Github Action check out Chads example repo
https://github.com/metcalfc/docker-action-examples. You can make use of the features in here or some of the more advanced features we can now offer with the V2 action such as push to multiple registries, use of a local registry for e2e test, export an image to the Docker client and more! 

To learn more about the changes to our Github Action, have a read through our updated usage documentation or check out our blog post on the best practices with Docker and Github Actions. If you have questions or feedback on the changes from V1 to V2 please raise tickets on our repo or our public roadmap

]]>
Docker Github Actions https://www.docker.com/blog/docker-github-actions/ Tue, 22 Sep 2020 15:00:00 +0000 https://www.docker.com/blog/?p=27053 In our first post in our series on CI/CD we went over some of the high level best practices for using Docker. Today we are going to go a bit deeper and look at Github actions. 

We have just released a V2 of our GitHub Action to make using the Cache easier as well! We also want to call out a huge THANK YOU to @crazy-max (Kevin :D) for the of work he put into the V2 of the action, we could not have done this without him! 

Right now let’s have a look at what we can do! 

To start we will need to get a project setup, I am going to use one of my existing simple Docker projects to test this out:
github actions 1

The first thing I need to do is to ensure that I will be able to access Docker Hub from any workflow I create, to do this I will need to add my DockerID and a Personal Access Token (PAT) as secrets into GitHub. I can get a PAT by going to https://hub.docker.com/settings/security and clicking ‘new access token’, in this instance I will call my token ‘whaleCI’

github actions 2

I can then add this and my username as secrets into the GitHub secrets UI:
github actions 3

Great we can now start to set up our action workflow to build and store our images in Hub. In this CI flow I am using two Docker actions, the first allows me to log in to Docker Hub using my secrets store in my GitHub Repository. The second is the build and push action, in this I am setting the push flag to true (as I want to push!) and adding in my tag simply to always go to latest. Lastly in this I am also going to echo my image digest to see what was pushed. 

name: CI to Docker hub 

on:

  push:

    branches: [ master ]

  steps:

      -

        name: Login to DockerHub

        uses: docker/login-action@v1 

        with:

          username: ${{ secrets.DOCKER_HUB_USERNAME }}

          password: ${{ secrets.DOCKER_HUB_ACCESS_TOKEN }}

      -

        name: Build and push

        id: docker_build

        uses: docker/build-push-action@v2

        with:

          context: ./

          file: ./Dockerfile

          push: true

          tags: bengotch/simplewhale:latest

      -

        name: Image digest

        run: echo ${{ steps.docker_build.outputs.digest }}

Great, now I will just let that run for the first time and then tweak my Dockerfile to make sure the CI is running and pushing the new image changes:
github actions 4

Next we can look at how we can optimize this; the first thing I want to do is look at using my build cache. This has two advantages, first this will reduce my build time as it will not have to re-download all of my images and second it will reduce the number of pulls I complete against Docker Hub. To do this we are going to leverage the GitHub cache, to do this I need to set up my builder with a build cache.

The first thing I want to do is actually set up a Builder, this is using Buildkit under the hood, this is done very simply using the Buildx action.

  steps:
      -
        name: Set up Docker Buildx
        id: buildx
        uses: docker/setup-buildx-action@master

Next I need to set up my cache for my builder, here I am adding the path and keys to store this under using the github cache for this. 

     -
        name: Cache Docker layers
        uses: actions/cache@v2
        with:
          path: /tmp/.buildx-cache
          key: ${{ runner.os }}-buildx-${{ github.sha }}
          restore-keys: |
          ${{ runner.os }}-buildx-

And lastly having added these two bits to the top of my Action file I need to add in the extra attributes to my build and push step. Here I am setting the builder to use the output of the buildx step and then using the cache I set up for this to store to and retrieve from.

 -
        name: Login to Docker Hub
        uses: docker/login-action@v1 
        with:
          username: ${{ secrets.DOCKER_HUB_USERNAME }}
          password: ${{ secrets.DOCKER_HUB_ACCESS_TOKEN }}
      -
        name: Build and push
        id: docker_build
        uses: docker/build-push-action@v2
        with:
          context: ./
          file: ./Dockerfile
          builder: ${{ steps.buildx.outputs.name }}
          push: true
          tags:  bengotch/simplewhale:latest
          cache-from: type=local,src=/tmp/.buildx-cache
          cache-to: type=local,dest=/tmp/.buildx-cache
      -
        name: Image digest
        run: echo ${{ steps.docker_build.outputs.digest }}

Great, now we can run it again and I can see that I am using the cache!

Now we can look at how we can improve this more functionally by adding in the ability to have our tagged versions we want to be released to Docker Hub behave differently to my commits to master (rather than everything updating latest on Docker Hub!). You might want to do something like this to have your commits go to a local registry to then use in nightly tests so you can always test what is latest while reserving your tagged versions for release to Hub. 

To start we will need to modify our previous GitHub workflow to only push to Hub if we get a particular tag:

on:
 push:
   tags:
     - "v*.*.*"

This now means our main CI will only fire if we tag our commit with V.n.n.n, let’s have a quick go and test this:

github actions 5

And when I check my GitHub action: 

github actions 6

Great!

Now we need to set up a second GitHub action file to store our latest commit as an image in the GitHub registry, you may want to do this to run your nightly tests or recurring tests against or to share work in progress images with colleagues. To start I am going to clone my previous GitHub action and add back in our previous logic for all pushes. 

Next I am going to change out our Docker Hub login to a GitHub container registry login

    	if: github.event_name != 'pull_request'
    	uses: docker/login-action@v1
    	with:
      	registry: ghcr.io
      	username: ${{ github.repository_owner }}
      	password: ${{ secrets.ghcr_TOKEN }}

And I will also need to remember to change how my image is tagged, I have opted to just keep latest as my only tag but you could always add in logic for this:

  tags: ghcr.io/nebuk89/simplewhale:latest

Now we will have two different flows, one for our changes to master and one for our pull requests. Next we will need to modify what we had before so we are pushing our PRs to the GitHub registry rather than to Hub. 

We could now look at how we set up either nightly tests against our latest tag, how we want to test each PR or if we want to do something more elegant with the tags we are using and make use of the Git tag for the same tag in our image. If you would like to look at how you can do one of these or get a full example of how to setup what we have gone through today please check out Chad’s repo which runs you through this and more details on our latest GitHub action: https://github.com/metcalfc/docker-action-examples 

And keep an eye on our blog for new posts coming in the next couple of weeks looking at how we can get this setup on other CIs, if there are some in particular you would like to see reach out to us on Twitter on @docker.
To get started setting up your GitHub CI with Docker Hub today sign up for a Docker account and have a go with Docker’s official GitHub actions.

]]>
Docker Support for the New GitHub Container Registry https://www.docker.com/blog/docker-support-for-the-new-github-container-registry/ Tue, 01 Sep 2020 17:01:00 +0000 https://www.docker.com/blog/?p=26983 Docker and GitHub continue to work together to make life easier for developers. GitHub today announced a new container registry: GitHub Container Registry. GitHub and Docker both occupy essential components in the developer workflow for building and deploying cloud native applications so we thought we would provide some insight into how the new tooling benefits developers. 

dockergithub

Found at ghcr.io, the new GitHub registry adds support for anonymous pulls and decouples git repositories permissions from container registry’s permissions. This allows projects to have private git repositories with a public container registry or vice versa. Other features like OCI compliance, Helm charts, and support for GITHUB_TOKEN are expected later. 

The GitHub Container Registry was built with Docker in mind so your Docker Engines and Docker Desktops will seamlessly work with this new registry.  Let’s take a look at this in action over at our upcoming Docker Login GitHub Action:

name: ci
on:
  push:
    branches: master
jobs:
  login:
    runs-on: ubuntu-latest
    steps:
      -
        name: Checkout
        uses: actions/checkout@v2
      -
        name: Login to GitHub Package Registry
        uses: docker/login-action@v1
        with:
          registry: ghcr.io
          username: ${{ github.repository_owner }}
          password: ${{ secrets.GHCR_TOKEN }}

That is all you need to do. When you compare this against the the job for a GitHub packages repository you just needed to update two lines:

  • registry: docker.pkg.github.com becomes registry: ghcr.io Fourteen fewer characters to type, FTW.
  • password: ${{ secrets.GITHUB_TOKEN }} becomes password: ${{ secrets.GHCR_TOKEN }}. Unfortunately what this means is the automatically generated GITHUB_TOKEN will not work for authentication for the initial release. You will have to go to GitHub, generate a personal access token, and create a GitHub Action secret. You can read more about this in the documentation here. We believe that GITHUB_TOKEN support will be released later.

Once that is done you are ready to go. You can continue on to docker build and docker push to your heart’s content. There are lots of different use cases across the container lifecycle.  For a more complete example from CI to production, using both GitHub Container Registry and Docker Hub, including a bonus preview of our upcoming Docker Buildx action, go to my example repository. 

From the 11 billion images pulled a month to the 7 million developers Docker Hub will always be there for the developer. Portability and choice have always been core to the Docker experience. We are always excited to work with our friends at GitHub to make the best possible experience for our customers, users, and community. 

If you are ready to get started with Docker, we offer free plans for individual developers and teams just starting out. Get started with Docker today.

]]>
First Docker GitHub Action is here! https://www.docker.com/blog/first-docker-github-action-is-here/ Tue, 17 Mar 2020 09:45:12 +0000 https://www.docker.com/blog/?p=25749 We are happy to announce that today Docker has released its first Github Action! We’ve been working with GitHub, looking into how developers have been using GitHub Actions with Docker to set up their CI/CD workflows. The standard flows you’ll see if you look around are what you’d expect: building an image, tagging it, logging into Hub, and pushing the image. This is the workflow we’ve aimed to support with our Docker build-push action.

Simplify CI/CD workflows

At Docker traditionally much of our CI/CD workflows has been handled through Jenkins using a variety of products to set up and maintain it. For some things this is the best solution like when we are testing Docker Desktop on a whole variety of different hosts and configurations. For others it’s a bit overkill. Like many, we at Docker have been looking at how we can leverage GitHub Actions to simplify our workflows, including how we use Docker itself.

GitHub Actions already leverages Docker in a lot of its workflows. From having Docker pre-installed and configured on the cloud runners to having first class support for containerized actions allows developers to easily use the same Docker workflows they use locally to configure their repo’s CI/CD. Combined with multi-stage builds and you have a powerful environment to work with. 

Docker actions

When we started with Github Actions there were no built-in actions to handle our main build, tag and push flow so we end up with a yaml file, that can’t yet be run locally, full of bash commands. Indeed that’s exactly what you’re given if you choose the “Docker Publish” workflow template from inside GitHub. Though it’s certainly doable it’s not as easy to read and maintain as a script that just uses pre-built actions. This is likely why the community has already published a whole host of actions to do just that. Just go to the GitHub Marketplace and search for Docker actions.

Common things you’ll see beyond just the standard build/tag/push is supporting automatic tagging of images based on the branch you’re building from, logging in to private registries, and setting standard CLI arguments like the Dockerfile path.

Having looked at a number of these we decided to build our own actions off of these ideas and publish them back to the community as official Docker supported GitHub Actions. The first of these, docker/build-push-action, supports much of what has been written above and attempts to build and push images with what we consider to be best practices including:

  • Tagging based on the git ref (branches, tags, and PRs).
  • Tagging with the git SHA to make it easy to grab the image in later stages of more complex CI/CD flows. For example where you need to run end-to-end tests in a large, self-hosted cluster.
  • Labelling the image with Open Container Initiative labels using data pulled from the GitHub Actions environment.
  • Support for build time arguments and multi-stage targets.
  • Push filter that allows you to configure when just to build the image and when to actually push it depending on any of the data supplied by GitHub Actions and your own scripts. See the examples for one we use ourselves.

A single action approach

But why one big action instead of many small ones? One thing that came up in our discussions with GitHub is how they envisaged that users would create many small actions and chain them together using inputs and outputs but the reality looks to be the opposite. From what we had seen users have been creating big actions and handling the flows internally using inputs for configuration details.

Whilst developing our own actions we found ourselves going the same way, firstly because it’s simply easier to test that way as there currently isn’t any way to run the workflow script locally.

Also this:

name: build
  id: build
  uses: docker/build-action@v1
  with:
    repository: myorg/myrepo
    tags: v1
name: login
  uses: docker/login-action@v1
  with:
    registry: myregistry
    username: ${{ DOCKER_USERNAME }}
    password: ${{ DOCKER_PASSWORD }}
name: push
  uses: docker/push-action@v1
  with:
    registry: myregistry
    tags: ${{ outputs.build.tags }}

Is a bit more effort to write than:

name: build-push
  uses: docker/build-push-action@v1
  with:
    username: ${{ DOCKER_USERNAME }}
    password: ${{ DOCKER_PASSWORD }}
    registry: myregistry
    repository: myorg/myrepo
    tags: v1

The final reason we went with the single action approach was that the logic of how the separate steps link and when they should be skipped is simple to handle in the backend based purely on a couple of inputs. Are the username and password set? Then do a login. Should we push? Then push with the tags that we built the image with. Is the registry set? Then log in to that registry, tag the images with that registry, and push to it rather than defaulting to Docker Hub.

Feedback is welcome!

All of this is handled by the image that backs the action. The backend is a simple go program that shells out to the Docker CLI, the code for which can be found here and is built and pushed using the action itself. As always, feedback and contributions are always welcome.

Screenshot 2020 03 23 at 15.24.46

If you want to try out our Docker Github Action you can find it here or if you haven’t used Github actions before you can find a guide to get started by Github here. For more news on what else to expect coming soon from Docker remember to look at our public roadmap

]]>