Docker at SnykCon 2020

We are excited to be a gold sponsor of the inaugural SnykCon virtual conference, a free online event from Snyk taking place this week on October 21-22, 2020. The conference will look at best practices and technologies for integrating development and security teams, tools, and processes, with a specific nod of the secure use of containers, from images used as a starting point to apps shared with teams and the public.

At Docker, we know that security is vital to successful app development projects, and automating app security early in the development process ensures teams start with the right foundation and ship apps that have vulnerability scanning and remediation included by default. This year we announced a broad partnership with Snyk to incorporate their leading vulnerability scanning across the entire Docker app development lifecycle. At Snykcon, attendees will learn how to successfully incorporate security scanning into their entire Docker app delivery pipeline.

Some of the highlights from Docker at this event include:

Docker CEO Scott Scott Johnston will join Snyk CEO Peter McKay in the keynote fireside chat on Thursday, October 22 at 8:30am PDT. Scot and Peter will talk about the partnership between Docker and Snyk and share new collaboration between the companies that strengthen the integration of Snyk scanning into Docker container workflows. 

Later that day, Docker’s Justin Cormack will deliver a breakout session with Danielle Inbar from Snyk on how to secure containers directly from Docker Desktop. In this session, Justin and Danielle will take you on a technical deep dive into how you can integrate Snyk and Docker for continuous integrated security scanning, in your command line and throughout the SDLC. This session will give you an insider’s perspective to quickly start benefiting from these new integrations.

You can get more details about these sessions, as well as the rest of the Snykcon program at the Snykcon agenda page. 

Snykcon starts this Wednesday, but it’s not too late to register (and it’s free!).

Simply go to the Snykcon registration page and sign up today. I look forward to “seeing” you online this Wednesday and Thursday!
The post Docker at SnykCon 2020 appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Improve the Security of Hub Container Images with Automatic Vulnerability Scans

In yesterday’s blog about improvements to the end-to-end Docker developer experience, I was thrilled to share how we are integrating security into image development, and to announce the launch of vulnerability scanning for images pushed to the Hub. This release is one step in our collaboration with our partner Snyk where we are integrating their security testing technology into the Docker platform. Today, I want to expand on our announcements and show you how to get started with image scanning with Snyk. 

In this blog I will show you why scanning Hub images is important, how to configure the Hub pages to trigger Snyk vulnerability scans, and how to run your scans and understand the results. I will also provide suggestions incorporating vulnerability scanning into your development workflows so that you include regular security checkpoints along each step of your application deployment.  

Software vulnerability scanners have been around for a while to detect vulnerabilities that hackers use for software exploitation. Traditionally security teams ran scanners after developers thought that their work was done, frequently sending code back to developers to fix known vulnerabilities. In today’s “shift-left” paradigm, scanning is applied earlier during the development and CI cycles but most organizations have to build their own automation to connect the scan functions to the CI instruments. Yesterday’s release changes this equation and provides built in automated scanning as an integral step within the CI cycle.  

Now you decide which repos to configure for vulnerability scanning to trigger a scan every time you push an image into that repo, and when the scan is completed you can view the scan results in your Hub account. Vulnerability data is organized in the Hub in several different layers: vulnerability severity summary, list of all vulnerabilities, and detailed information about a specific security flaw. The scanning function is available for Pro and Team users, creating a simple method of validation for each image update.

How It Works

Step 1 – Enable Repo Scanning Functions

Enabling repo scanning is a simple, single-click process, but the default setting is for disabled scanning so make sure you turn it on.

Scanning is separately configurable for each repo so you can decide how you want to start incorporating scanning into your team collaboration cycles and application build steps. You can adopt these processes on a smaller scale and over time expand them to the rest of your organization. Conversely, if you decide that the repo that you have been scanning is no longer an active part of your development, you can use the same single-click option to disable scanning.

Step 2 – Run your scans

Once you enable scanning, each time that you push a tagged image into that repo you will automatically trigger a scan.  

Step 3 – View the Results

After vulnerability scanning is completed, you can go to the repo page in the Hub to view the scan results. General Tab of the Hub Repo page includes results summary for all the repo image scans which will show the number of high, medium and low vulnerabilities identified during each scan.  

Clicking on the Vulnerabilities section of a specific tag brings you to the Vulnerability Tab for that tag, which shows the total number of vulnerabilities identified during the scan. Vulnerabilities Tab includes the scan severities summary and shows you the full list of scan vulnerabilities.  

The vulnerability list is organized so that you will see the most critical vulnerabilities first. The higher severity issues are prioritized above the lower ones, and the same severity vulnerabilities are organized in the descending order for the Common Vulnerability Scoring System (CVSS) .  CVSS scores are a published standard for assigning numerical value to the severity of software vulnerabilities. Vulnerability list also includes Common Vulnerabilities and Exposures (CVEs), which are identification numbers for publicly known cybersecurity vulnerabilities as well as name and version of a package containing this vulnerability. If available, the ‘Fixed In’ column includes a higher version of the same package that has the vulnerability resolved. This is a very important part that gives you clear guidance on how to rebuild your image without the vulnerability.  

Next to the ‘Fixed In’ column is a pop-up link to a page on the Snyk website, presenting detailed information about that specific vulnerability.

The little arrow located next to the Severity rating indicates that this vulnerability has dependencies. Clicking on this arrow expands the vulnerability box and displays these dependencies:

Learn More and Try It For Yourself

Hub scanning is already available. Please check the Docker Doc section link below for more information on how to get started and give us feedback: 

https://docs.docker.com/docker-hub/vulnerability-scanning/

To learn more from experts about getting the most from Docker Hub vulnerability scanning, please plan on joining Docker’s Peter McKee and Snyk’s Jim Armstrong for a joint webinar on Wednesday, Oct 15.  Register now!
The post Improve the Security of Hub Container Images with Automatic Vulnerability Scans appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

New Vulnerability Scanning, Collab and Support Enhance Docker Pro and Team Subscriptions

Last March, we laid out our commitment to focus on developer experiences to help build, share, and run applications with confidence and efficiency. In the past few months we have delivered new features for the entire Docker platform that have built on the tooling and collaboration experiences to improve the development and app delivery process.

During this time, we have also learned a lot from our users about ways Docker can help improve developer confidence in delivering apps for more complicated use cases and how we can help   larger teams improve their ability to deliver apps in a secure and repeatable manner. Over the next few weeks, you will see a number of new features delivered to Docker subscribers at the free, Pro and Team level that deliver on that vision for our customers. 

Today, I’m excited to announce the first set of features: vulnerability scanning in Docker Hub for Pro and Team subscribers. This new release enables individual and team users to automatically monitor, identify and ultimately resolve security issues in their applications. We will also preview Desktop features that will rollout over the next several months.   

We’ve heard in numerous interviews with team managers that developer velocity is critical, that automation enables this and that images going into production have to be secure. Last month we launched Docker local image scans as preview in Desktop Edge and today we are releasing vulnerability scanning in Docker Hub. Starting now each time that you push images into Docker Hub, a vulnerability scan will run automatically using the same underlying tooling as our Docker Scan CLI. Once the scan is complete, you can review the scan results in your Docker Hub dashboard. Look out for a deeper dive into the Hub image scanning in the coming days.  

Improved Collaboration and Control

We are also thrilled to start talking to you about Docker’s plans for Docker Desktop and how we are going to add unique improvements for Desktop for Pro and Team users. Starting in November Pro and Team users of Desktop will get additional features and benefits designed to meet the unique needs of teams and of complex use cases, on top of the core features in the free edition. The first feature will provide visibility of Docker Hub scan results directly within the Docker Dashboard for all of your Hub images. In the coming months we will enable users of Docker Context to store and share your contexts with your team from the Desktop via Docker Hub, allowing development teams to collaborate with the same set of contextual details for shared remoted instances. 

For enterprises who want more control over their version of Desktop and don’t want to keep dismissing updates, we will be providing the ability to ‘ignore’ updates in Desktop until you choose to install the new version. Additionally, we allow for centralized deployment and management of Docker Desktop teams at scale through revised licensing terms for Docker Teams. This will allow larger deployments of Docker Desktop to be rolled out automatically rather than relying on individuals to install it on their own.

Finally, we will also extend the Docker enhanced customer support to include Docker Desktop as well as Docker Hub. Docker Pro and Team subscribers will be assured of consistent support from Docker across all offerings in their subscriptions as they build, share and run their containerized applications. 

We will continue to add more Pro and Team features across the entire Docker platform to make developers’ and teams’ lives easier over the coming months.  And of course, we will continue to improve and enhance our core, free offerings. 

 To test Hub scanning today, sign up for a Pro Docker account.   Or,  try the experience locally and run docker scan on your Desktop CLI. If you are interested in Docker Desktop, and what the future holds, then keep an eye on our product roadmap.  If you have questions about deployment licensing or support, please reach out to us.

CTA: 

Sign up for Docker HubRegister for the Webinar: Adding Container Security to Docker Hub with Snyk on October 15th at 10AM PT Join our YouTube Live: Synk Image Scanning on Oct. 8th at 10AM PT

More info on Docker Subscriptions for Pros and Teams
The post New Vulnerability Scanning, Collab and Support Enhance Docker Pro and Team Subscriptions appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

The Docker Dashboard Welcomes Hub and Local Images

Last year we released the Docker Dashboard as part of Docker Desktop, today we are excited to announce we are releasing the next piece of the dashboard to our community customers with a new Images UI. We have expanded the existing UI for your local machine with the ability to interact with your Docker images on Docker Hub and locally. This allows you to: display your local images, manage them (run, inspect, delete) through an intuitive UI without using the CLI. And for you images in Hub you can now view you repos or your teams repos and pull images directly from the UI. 

To get started, Download the latest Docker Desktop release and load up the dashboard (we are also excited that we have given the dashboard an icon)

You will be able to see that we have also added a new sidebar to navigate between the two areas and we are planning to add new sections in here soon. To find out more about what’s coming or to give feedback on what you would like to see check out our public roadmap. 

Let’s jump in and have a look at what we can do…

From the whale menu, you can access the “Dashboard” and then “Images” where you’ll see a summary and each image with its details: tag, image id, creation date, and size. 

I can also see which of my images are being used by a running or stopped container with 

Now I have all these images, I can have a go at running one of them.I will go for my standard demo my simple Whale, when I hover over the image line I can see I get two new buttons, I am going to start off by clicking ‘run’ 

This pops up a UI where you can either just ‘run’ or add in some values. In this instance I am just going to add a port mapping so I can see what is running in my container once I have started it. 

Great this now takes me to my running container UI and I can see that my container is alive! 

Next let’s look at clearing up what we have not used so far. I am going to start by hitting the clean up button we saw in the top right corner of our images UI 

Then my UI changes, I am going to remove all my unused images, I can see I will free up 4gb which isn’t bad!

I hit remove up and I can then see after I accept the warning my clean up happens I only have my in use images remaining! 

Now let’s have a look at our Hub images, as I am signed in I can just click on the remote repositories tab

Great! I can now see my repos in Hub along with my tags, I can either pull my image to then run it or I can switch between my Teams to see the repositories in my teams. If I click pull on one of my images, I can see this is started as it takes me back to my local image cache screen and shows me the progress of the download:

I’ve also created an “unboxing” walkthrough of the entire process. You can join me on a guided tour of the new features in this video.

We hope you are as excited as we are for the next piece of our Docker Dashboard, to get started you can download the latest Docker Desktop release to explore your local images. You can try out the Remote Repository functionality by signing into Docker Hub and pulling any of your existing images or if you are new why not try pulling a Docker Official Image like NGINX , retagging it and then having a go at pushing it from the UI.
The post The Docker Dashboard Welcomes Hub and Local Images appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Docker Names Donnie Berkholz to Vice President of Products

To deepen Docker’s investment in products that make developers successful, we’re pleased to announce that Donnie Berkholz will join the Docker team as VP of Products. Donnie has an extensive background as a practitioner, leader, and advisor on developer platforms and communities. He spent more than a decade as an open-source developer and leader at Gentoo Linux, and he recently served as a product and technology VP at CWT overseeing areas including DevOps and developer services. Donnie’s also spent time at RedMonk, 451 Research, and Scale Venture Partners researching and advising on product and market strategy for DevOps and developer products.

To get to know Donnie, we asked him a few questions about his background and where he plans to focus in his new role:

What got you the most excited about joining Docker? 

I’ve been a big fan of Docker’s technology since the day it was announced. At the time, I was an industry analyst with RedMonk, and I could instantly sense the incredible impact that it would have in transforming the modern developer experience. Recent years have borne that out with the astonishing growth in popularity of containers and cloud-native development. With Docker’s renewed focus on developers, I’m really excited to help shape products that have a natural fit with Docker’s user base.

What are your main goals now that you’re part of the Docker team?

Everything tends to fall into place when you’ve got a great team who’s aligned and empowered. As VP of Products, I’ll be making sure our team has everything they need to succeed, continuing to evolve our product strategy and vision, and driving execution with an experimental mindset. What I mean by that is ensuring we have a culture and way of working that allows us to continuously innovate and learn fast — in partnership with the broader Docker team, as well as our partners, customers and the millions of developers who use Docker.

We have an amazing community of Docker users, and I’m really excited about making their lives better by solving some of their biggest and most frustrating problems as they develop software.

What will you focus on most in the next few months as you work to shape great products for developers?

My initial priorities when starting any new role are to build relationships and to learn. First, collaboration is such a critical aspect of success in any organization that it’s vital to form high-trust relationships, so you can partner closely and cross-functionally. Second, learning how and why things are done the way they are is crucial, so you don’t come in with a plan from a playbook that seems grand but doesn’t fit the needs of the organization. Once those are in place, my focus will shift toward getting us from where we are today to where we’ll need to be, so we can reach and exceed our ambitious goals.

When you’re not focused on making Docker better, what hobbies or interests do you have?

I love to read sci-fi and fantasy books, especially these little niches called wuxia or xianxia. If you imagine “Crouching Tiger, Hidden Dragon” or “Kung Fu Hustle,” you’ll get the idea. Besides that, I’m a big fan of craft beer. So let me know if any of you visit Minneapolis or (in a future world!) we attend the same event, because I’d love to share a beverage of any sort with our community.
The post Docker Names Donnie Berkholz to Vice President of Products appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Docker Open Sources Compose for Amazon ECS and Microsoft ACI

Today we are open sourcing the code for the Amazon ECS and Microsoft ACI Compose integrations. This is the first time that Docker has made Compose available for the cloud, allowing developers to take their Compose projects they were running locally and deploy them to the cloud by simply switching context.

With Docker focusing on developers, we’ve been doubling down on the parts of Docker that developers love, like Desktop, Hub, and of course Compose. Millions of developers all over the world use Compose to develop their applications and love its simplicity but there was no simple way to get these applications running in the cloud.

Docker is working to make it easier to get code running in the cloud in two ways. First we moved the Compose specification into a community project. This will allow Compose to evolve with the community so that it may better solve more user needs and ensure that it is agnostic of runtime platform. Second, we’ve been working with Amazon and Microsoft on CLI integrations for Amazon ECS and Microsoft ACI that allow you to use docker compose up to deploy Compose applications directly to the cloud.

While implementing these integrations, we wanted to make sure that existing CLI commands were not impacted. We also wanted an architecture that would make it easy to add new backends and provide SDKs in popular languages. We achieved this with the following architecture:

The Node SDK and Compose CLI parts of this diagram are what we have open sourced today. This architecture is not final and we plan to merge the Compose CLI with the existing CLI at a later time.

Depending on the Docker Context that the user selects, the Compose CLI switches which backend is used for the command or API call. This allows us to pass commands which use existing contexts to the existing CLI transparently. The backend interface abstraction allows the implementation of a backend for any container runtime so that users can get the same Docker CLI UX they know and love for it along with the new APIs and SDK.

The Compose CLI can serve a gRPC API to provide similar functionality to that of the CLI commands. We chose to use gRPC as this allows us to generate high quality SDKs in popular languages like Node.js, Python, and Golang. While we currently only provide a Node SDK that supports single container management on ACI, there are plans to add Compose support, extend it to ECS and other backends, and add other language SDKs in the near future. The Node SDK is already used by VS Code to implement its Docker experience on ACI.

This work wouldn’t have been possible without help from our partners at Microsoft and AWS who helped us build the best possible experience for their respective platforms. Our team has enjoyed working with all of you! From Microsoft we’d specifically like to thank Mike Morton, Karol Zadora-Przylecki, Brandon Waterloo, MacKenzie Olson, and Paul Yuknewicz. From AWS we’d like to thank Carmen Puccio, David Killmon, Sravan Rengarajan, Uttara Sridhar, and David Duffey.

These tools are currently in beta so feedback and pull requests are welcome!

Compose CLI source: https://github.com/docker/compose-cliNode SDK source: https://github.com/docker/node-sdk

To get started working with Compose in the Cloud you can download Docker Desktop here, get a free Hub account to deploy your images from here. Once you have you image saved to Docker Hub you will be able to deploy it to either ECS or ACI, to find out more about how to do this:

Read about how to use the Amazon ECS integration here: https://docs.docker.com/engine/context/ecs-integration/Read about how to use the Microsoft ACI integration here: https://docs.docker.com/engine/context/aci-integration/
The post Docker Open Sources Compose for Amazon ECS and Microsoft ACI appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Docker Github Actions

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:

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’

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

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:

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:

And when I check my GitHub action: 

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.
The post Docker Github Actions appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Best practices for using Docker Hub for CI/CD

According to the 2020 Jetbrains developer survey 44% of developers are now using some form of continuous integration and deployment with Docker Containers. We know a ton of developers have got this setup using Docker Hub as their container registry for part of their workflow so we decided to dig out the best practices for doing this and provide some guidance for how to get started. To support this we will be publishing a series of blog posts over the next few weeks to answer the common questions we see with the top CI providers.

We have also heard feedback that given the changes Docker introduced relating to network egress and the number of pulls for free users, that there are questions around the best way to use Docker Hub as part of CI/CD workflows without hitting these limits. This blog post covers best practices that improve your experience and uses a sensible consumption of Docker Hub which will mitigate the risk of hitting these limits and how to increase the limits depending on your use case. 

To get started, one of the most important things when working with Docker and really any CI/CD is to work out when you need to test with the CI or when you can do this locally. At Docker we think about how how developers work in terms of their inner loop (code, build, run, test) and their outer loop (push change, CI build, CI test, deployment) 

Before you think about optimizing your CI/CD, it is always important to think about your inner loop and how it relates to the outer loop (the CI). We know that most people aren’t a fan of ‘debugging via the CI’, so it is always better if your inner loop and outer loop are as similar as possible. To this end it can be a good idea to run unit tests as part of your docker build command by adding a target for them in your Dockerfile. That way as you are making changes and re-building locally you can run the same unit tests you would run in the CI on your local machine with a simple command. Chris wrote a blog post earlier in the year about Go development with Docker, this is a great example of how you can use tests in your Docker project and re-use them in the CI. This creates a shorter feedback loop on issues and reduces the amount of pulls and builds your CI needs to do.

Once you get into your actual outer loop and Docker Hub, there are a few things we can do to get the most of your CI and deliver the fastest Docker experience. 

Firstly and foremost stay secure! When you are setting up your CI make sure you are using a Docker Hub access token rather than your password, you can create new access tokens from your security page on Docker Hub. 

Once you have this and have added it to whatever secrets store is available on your platform you will want to look at when you decide to push and pull in your CI/CD along with where from depending on the change you are making. The first thing you can do here to reduce the build time and reduce your number of calls is make use of the Buildcache to reuse layers you have already pulled. This can be done on many platforms by using BuildX/buildkits caching functionality and whatever cache your platform provides.

The other change you may want to make is only have your release images go to DockerHub, this would mean setting up functions to push your PR images to a more local image store to be quickly pulled and tested rather than promoting them all the way to production.

We know there are a lot more tips and tricks for using Docker in CI but really looking at how to do this around the recent Hub rate changes we think these are the top things you can do.

If you are still finding you have issues with Pull limits once you are authenticated you can consider upgrading to either a Pro or a Team account. This will give you unlimited authenticated pulls from Docker Hub, along with giving you unlimited private repos and unlimited image retention. In the near future this will also include Image Scanning (powered by Snyk) on push of new images to Docker Hub.

Look out for the next blog post in the series about how to put some of these practices into place with Github actions and feel free to give us ideas of what CI providers you would like to see us covering by dropping us a message on Twitter @Docker.
The post Best practices for using Docker Hub for CI/CD appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/