pulumi-community #kubernetes

flat-insurance-25294

10/01/2020, 6:29 PM

@loud-battery-37784 I wonder if there is an approach where we can first try to “fetch” an image based on a tag/version and if it doesn’t exist, use

buildAndPushImage

This way I should technically get what I want - where the only “new” thing is the replica count, while the image stays the same. Depending on how Pulimi does its

kubectl

command where the only “new” thing should be the replica count.

loud-battery-37784

10/01/2020, 6:33 PM

I would think so. One of the reasons we moved to Pulumi from Terraform is being able to write our IaC in a turing complete language like TypeScript. Much easier to customize functionality like what you’re saying. Create an

if/else

block and do work.

loud-battery-37784

10/01/2020, 6:34 PM

Personally, I like the way it’s implemented currently. If the code executes it happens. It’s up to me to decide if the code should execute not the tool.

flat-insurance-25294

10/01/2020, 6:42 PM

I’m leaving this open ended in case I’ve misunderstood something but… That seems counter intuitive, my assumption is that Pulumi manages state, if that contract is broken, then the tool becomes unreliable (I am not saying that is the case!) I am just saying that if the only thing I change between “pulumi up” is the

replica

count then that’s the only thing I want to change. Docker today already has the concept of layer hash. If no layer has changed, then that means no new image is necessary.

broad-dog-22463

10/01/2020, 6:50 PM

Pulumi knows when the image changes locally

broad-dog-22463

10/01/2020, 6:50 PM

If nothing changes in the image then it will just redeploy the same image

broad-dog-22463

10/01/2020, 6:51 PM

Pulumi doesn’t run Kubectl / it talks to the APIs directly

flat-insurance-25294

10/01/2020, 9:00 PM

@broad-dog-22463 Oh so how does it work? In

pulumi up

a second time where

replica

number has changed, how does it make sure it’s not using a new image when using

buildAndPushImage

broad-dog-22463

10/01/2020, 9:03 PM

So the state has the name of the image associated with the deployment and will scale out because that’s the parameter that has changed

broad-dog-22463

10/01/2020, 9:03 PM

It’s an idempotent operation

broad-dog-22463

10/01/2020, 9:04 PM

Or it should be and if it reports differently then it’s a bug and something needs fixed

broad-dog-22463

10/01/2020, 9:04 PM

If a change is made manually then you need to run “Pulumi refresh” to update the Pulumi state with the latest changes from this manual update

flat-insurance-25294

10/01/2020, 9:05 PM

@loud-battery-37784 In our case, we’re using

branch_names:latest

for everything except

master

develop

With separate repositories for each branch.

develop

and

master

branches share the same repository.

develop

will use automated

commit sha

as a tag.

master

will use hand selected (manual typed)

commit sha

as image tag from the same ECR/Docker repository as

develop

flat-insurance-25294

10/01/2020, 9:10 PM

@broad-dog-22463 My question is Do I use

const image = buildAndPushImage(name: "app:23", pathOrBuild: "./app"): RepositoryImage

const image = new RepositoryImage(repository: repo, image: "app:23")

? if I want to get a specific

image

or build it, if it’s missing.

broad-dog-22463

10/01/2020, 9:11 PM

Build and push image doesn’t talk to kubernetes - it’s talking to ECR AFAIcR

flat-insurance-25294

10/01/2020, 9:11 PM

Yeh, and that should have sufficient information to pick apart details for knowing if it’s fetching an existing image, or building a new one because something changed, correct?

broad-dog-22463

10/01/2020, 9:12 PM

BuildAndPushImage will build a local image and push the changes to ecr if there are any

broad-dog-22463

10/01/2020, 9:12 PM

It’s a wrapper that sits over Pulumi-docker

flat-insurance-25294

10/01/2020, 9:13 PM

What predicates does it use to figure out if there are changes or does it offset that to Docker defaults -> using layer hashes, and other stuff I am not aware of?

flat-insurance-25294

10/01/2020, 9:14 PM

Because if that’s the case, it still needs to build it and compare final hashes in order to decide if something needs to be pushed or not. But the build aspect needs to happen - which makes it less idempotent, if something is changed upstream, maybe some dependency or whatever - obviously a dockerfile should be as idempotent as possible, but still room for errors, I am just figuring out how it works so I can make a better decision.

broad-dog-22463

10/01/2020, 9:15 PM

It runs docker commands under the hood

flat-insurance-25294

10/01/2020, 9:15 PM

It seems like @loud-battery-37784 was correct. It needs to do a form of “get or make” conditional.

flat-insurance-25294

10/01/2020, 9:16 PM

@broad-dog-22463 To clarify, docker commands under the hood is building - but will Pulumi compare hashes before deciding to push to the registry/repository?

broad-dog-22463

10/01/2020, 9:17 PM

Yes

broad-dog-22463

10/01/2020, 9:17 PM

It will not update an image in the registry unless it has changed

broad-dog-22463

10/01/2020, 9:18 PM

But if that image changes outside of Pulumi then Pulumi won’t know that without a Pulumi refres

broad-dog-22463

10/01/2020, 9:18 PM

As it keeps track of the state

flat-insurance-25294

10/01/2020, 9:18 PM

Let me clarify a bit further: The problem here is that the image used for a

Deployment/Pod

spec is computed from whatever Pulumi gives us as a result of its

awsx/ECR

API. It is not manually typed by us, we’re relying on the output of

const image = buildAndPushImage(name: "app:23", pathOrBuild: "./app")

To give consistent values so the only change is the

replica

count when Pulumi speaks with k8.

broad-dog-22463

10/01/2020, 9:18 PM

I don’t know what further clarification you need here?

broad-dog-22463

10/01/2020, 9:19 PM

We have examples of this in Pulumi/examples that you can test out and try it and see if changing the replicaCount does anything differently