App Promotion without re-build

Waypoint
1

The roadmap states:

App Promotion … Waypoint initially has the workspaces feature … This is a working but minimal feature targeted towards this use case.

And the Workspaces page states:

Operations such as deploy will deploy the latest built artifact from the same workspace .

As such, if you want to have a dev/staging/production set of environment in which an app is promoted from dev to test to production, does this mean you have to re-build the app in each workspace?

This seems like a problem for a core building block of immutable build artifacts that move through all environments.

Is there any worked around or suggested method of doing this?

1 Like
2

Hi @switchtrue,

This is technically possible, however, at present, you would need separate Waypoint.hcl files due to the way that resources are isolated in the workspace.

For example, your dev Workspace would use the following Waypoint configuration which would build a Docker image before deploying it.

project = "wpmini"

app "wpmini" {
  labels = {
    "service" = "wpmini",
    "env" = "dev"
  }

  build {
    use "pack" {} 

    registry {
      use "docker" {
        image = "docker-registry.container.shipyard.run:5000/wpmini"
        tag = "latest"
      }
    }
  }

  deploy {
    use "docker" {}
  }
}

This would be deployed with the commands:

waypoint init --workspace dev #only needed once
waypoint up --workspace dev

For the test or production environments, as you state you want to re-use the artifacts created in the dev workspace. At present, there is no automatic way of managing this in waypoint but you can achieve the same thing by using a slightly different Waypoint file.

In a test or release Waypoint file, you can replace the docker plugin which builds a container with the docker-pull plugin. This would re-use the image created in the dev workspace.

project = "wpmini"

app "wpmini" {
  labels = {
    "service" = "wpmini",
    "env" = "dev"
  }

  build {
    use "docker-pull" {
      image = "docker-registry.container.shipyard.run:5000/wpmini"
      tag = "latest"
    }
  }

  deploy {
    use "docker" {}
  }
}

Again you use the workspace command when running init and up, this time targeting the prod workspace.

waypoint init --workspace prod #only needed once 
waypoint up --workspace prod

This run would re-use the image built in a previous stage and deploy it to the production environment.

Different environments are something that we are going to be building on with subsequent releases of Waypoint.

Kind regards,

Nic

1 Like
3

Thanks, Nic. This sounds like a sensible approach.

Is there a recommended way of splitting the files? Can you have more than one Waypoint.hcl file and tell the waypoint cli which to use?

1 Like
4

Is there any advice on how this could work with multiple AWS accounts and ECS/ECR? Specifically we would like to deploy to a development AWS account, and promote to a production AWS account, all while storing the images in a shared account.

5

Hi @mbamber!

Waypoint should use AWS authentication available to the AWS go SDK such as content of the ~/.aws or env variables like $AWS_PROFILE when invoking waypoint commands.

So building on @nic 's example, an environment configured for the development AWS account would be responsible for referencing the shared image location in it’s waypoint.hcl registry section with the associated Waypoint workspace.

When interacting with production, set $AWS_PROFILE with the other waypoint.hcl file that references the docker-pull approach of reusing an existing image with the associated Waypoint workspace.

I have not verified the multi-account setup directly, but that’s my understanding of the way this works.

6

Ok, I think I understand. So the workflow would be to break the waypoint up command into different stages, and manually adjust the credentials between them. And then to promote that to production we would have a new waypoint.hcl file that replaces the use "docker" {} part of the build stanza with use "docker-pull" {}.

Could you also explain how we should manage multiple waypoint.hcl files? I noticed this in the docs, which suggests we would need these to be different projects?

Waypoint expects one waypoint.hcl per project or version control repository.

7

Actually I believe the promotion example Nic provided may not actually work as-is for a somewhat silly reason. The image from the 1st project that is pushed to the registry has the waypoint-entrypoint as it’s initial process. Then in the next project, when we use docker-pull plugin, it will add the waypoint-entrypoint again unless you have disable_entrypoint = false set as a variable in your build stanza, which could confuse things at runtime. So you can do something like this:

project = "wpmini"

app "wpmini" {
  labels = {
    "service" = "wpmini",
    "env" = "dev"
  }

  build {
    use "docker-pull" {
      image = "docker-registry.container.shipyard.run:5000/wpmini"
      tag = "latest"
      disable_entrypoint = true
   }
  }

  deploy {
    use "docker" {}
  }
}

Back to your other question about projects. Yes, because there are 2 different waypoint.hcl files, in 0.1 you need 2 separate projects which are in 2 separate directories (probably one named for each project name?). The 2 directories could be in the same source repository. Alternatively you might consider using the same repository and path, but support 2 different branches in the same repo. The waypoint.hcl contents for each branch could be different.

8

Re: your original post, being able to “logically” promote an image between multiple environments is something we want to support and that is hinting towards. i.e. it should be possible to do promote an already-built image from test => prod workspace without rebuild.

We also want to look into “physically” promoting an image between multiple environments that use separate repositories by perhaps doing a pull+push automatically.

I’m guessing this functionality may come separately but both are definitely on the radar!

1 Like
9

Hi All,

Is the promotion feature of deploying a same container version to different environments available now with waypoint?

10

Not yet, but this is still planned, probably at some point in the next few releases but not sure.

1 Like