3

Pass Built Docker Image from Build Pipeline to Release Pipeline

I'm currently successfully building a Docker image in a VSTS Build Pipeline. I would like to take this built image and then Publish it as a Build Artifact so that a VSTS Release Pipeline may use our AWS credentials to push the image to our Elastic Container Registry.

Currently I'm finding a bunch of workarounds involving either one or the other -- a single Build pipeline that builds the image then pushes it to ECR via CLI, or a single Release Pipeline with Bash tasks to build the image and then an ECR task to push.

I've tried a bunch of different things, including publishing the directory that Ubuntu stores the Docker containers in (didn't work due to permissions). I'm trying to maintain a consistent paradigm in my company of Build Pipelines doing the building and Release Pipelines doing the deployment; it seems that trying not to mince these two ideas for an ECR release may not be plausible.

Is this possible, and if so how? Thanks!

BrandonCookeDev
  • 33
  • 5
  • just create a service connection to ecr of a docker type and use it in docker push step? – 4c74356b41 Apr 04 '19 at 07:18
  • As I understand it, Service Connections are only available for use in Release Pipelines, which I would like to receive a built Docker image from a Build Pipeline then use the Service Connection to push to ECR. – BrandonCookeDev Apr 04 '19 at 11:34
  • no, they are available in both build and release pipelines – 4c74356b41 Apr 04 '19 at 11:36
  • It would still be preferable to me to split the paradigms of Building the docker image in a Build Pipeline and Pushing to ECR in a Release Pipeline. To me it makes the most sense to have those responsibilities distributed. Is that doable at this time? – BrandonCookeDev Apr 04 '19 at 11:54
  • thats exactly what is happening in my example. that build is only building the image. release will push it somewhere – 4c74356b41 Apr 04 '19 at 12:00
  • Apologies, I think I misunderstood you. So you're building the image and storing it in a local Container Registry, then a Release Pipeline will pull it out and perform the Push? – BrandonCookeDev Apr 04 '19 at 12:11
  • not the local one, its actually azure container registry, but it could be any other registry, so yeah. building image and pushing to the registry in the build and then release is applying it – 4c74356b41 Apr 04 '19 at 12:27
  • So I need a service connection to ACR to store the image so that a build pipeline may pick it up and push it to ECR? I understand the utility of this; however it seemingly defeats the purpose of what I was attempting. I wanted to publish it as a Build Artifact to avoid any sort of release paradigm inside the Build Pipeline. If this is the only method available at the current moment, then I understand. – BrandonCookeDev Apr 04 '19 at 12:39
  • m, i dont really see any value in this. you can do that build and package build artifacts and then create a docker image from the artifacts in the release pipeline, but why? there is no point in doing that – 4c74356b41 Apr 04 '19 at 12:41
  • I'm attempting not to mince the ideals of "Building" and "Releasing". To me a Build should include the process of creating the Docker image to be pushed, and a Release should be pushing that image to a Container Registry (ECR in this case). In the recommendation you made, the process of pushing is done in the Build process effectively making it a Release in my mind. Does that make sense? – BrandonCookeDev Apr 04 '19 at 12:51
  • it does, but it doesnt. there is no point in releasing a docker image. it doesnt do anything really. its like releasing a new package version. it doesnt go anywhere on its own. you are not doing releases of code right? you are doing builds. docker image is just another artifact – 4c74356b41 Apr 04 '19 at 12:53
  • The dockerfile does build the code into the image. It isn't like a template Docker image, it's actually an application. My Dockerfile COPY's in a Dotnet Core app, and builds it on the image. That image is then pushed to ECR where we can distribute that application how we choose. So in essence it is a Release of code. I'm unsure if that was important information left out, if so apologies. – BrandonCookeDev Apr 04 '19 at 12:58
  • i still dont see a reason to do a release of a container. because it doesnt break anything. its like piushing a zip file to a file share – 4c74356b41 Apr 04 '19 at 13:24
  • I think I'm beginning to understand your point. We aren't necessarily doing a code release so much as we are initiating the static storage of an artifact. In that sense, it isn't a release at all. That's what you're getting at, correct? – BrandonCookeDev Apr 04 '19 at 13:33
  • yeah, but if you really want to do it your way, you can still do that, package build results into an artifact (so you dont need docker steps\credentials at all in the build) and do packaging in the release by pulling those and building the container and pushing it – 4c74356b41 Apr 04 '19 at 13:37
  • I guess this was just a difference in ideals about what is a release, because in my mind it was the shipping of an app contained within an image. But thinking about an image as more of an artifact that is then released from a registry makes sense too, and gives me solace in the overall process I've been building. I appreciate all the help! – BrandonCookeDev Apr 04 '19 at 13:50

1 Answers1

-1

example yaml build that is using service connection:

jobs:
- job: build_server
  timeoutInMinutes: 30 
  pool:
    vmImage: 'Ubuntu-16.04'
  steps:
  - checkout: self
    clean: true

  - task: Docker@1
    inputs:
      containerregistrytype: 'Container Registry'
      dockerRegistryEndpoint: yyy
      imageName: xxx
      includeLatestTag: true
      dockerFile: dockerfile
  - task: Docker@1
    inputs:
      containerregistrytype: 'Container Registry'
      dockerRegistryEndpoint: yyy
      imageName: xxx
      command: push
4c74356b41
  • 69,186
  • 6
  • 100
  • 141
  • apologies, I'm not seeing the reference to Service Connection in the above example – BrandonCookeDev Apr 04 '19 at 11:58
  • just to verify, dockerRegistryEndpoint is actually the name of a Service Connection in the current VSTS Project right? – BrandonCookeDev Apr 04 '19 at 13:55
  • yeah, it is exactly that – 4c74356b41 Apr 04 '19 at 14:10
  • so if I may ask, is there a way for this Service Connection to be to ECR directly? I'm searching around but it is not looking promising right now. Due to our discussion above, it feels right that if we are going to push to a registry in the Build pipeline, we should skip the additional step of storing inside ACR and just go straight to ECR. – BrandonCookeDev Apr 04 '19 at 14:47
  • no, just use a docker connection, it should work with any compliant docker registry. i imagine it would work with ecr as well – 4c74356b41 Apr 04 '19 at 15:47