Skip to content

#1280 Fix Dockerfiles for .NET 6 SDK#1281

Merged
MihaZupan merged 3 commits into
dotnet:mainfrom
dpbevin:dev/bevo/fixup-dockerfiles
Oct 25, 2021
Merged

#1280 Fix Dockerfiles for .NET 6 SDK#1281
MihaZupan merged 3 commits into
dotnet:mainfrom
dpbevin:dev/bevo/fixup-dockerfiles

Conversation

@dpbevin
Copy link
Copy Markdown
Contributor

@dpbevin dpbevin commented Oct 9, 2021

Fixes #1280

imagePullPolicy: Always
image: <REGISTRY_NAME>/yarp-controller:<TAG>
imagePullPolicy: IfNotPresent
image: yarp/yarp-controller
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed this so that I don't have to keep modding the file locally to use it.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sadly we can't check in a reference to your image here for security reasons

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not publishing any images. This is simply a placeholder name for the local build process. The registry name <REGISTRY_NAME> is invalid, so it needs to be modified when working locally.
yarp could be replaced by anything really: local, donotuse, etc.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I trust you wouldn't, but presumably whoever owns the yarp name could potentially push an image to the repository tomorrow.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll revert that line until yarp publishes official image.

Comment thread .dockerignore
LICENSE
README.md No newline at end of file
README.md
**/ingress.yaml
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prevents unnecessary docker rebuilds when modifying the kube manifests

Copy link
Copy Markdown
Member

@MihaZupan MihaZupan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for fixing these up!

COPY ["src/", "src/"]
COPY ["Directory.Build.*", ""]
COPY ["global.json", ""]
COPY ["NuGet.config", ""]
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be simpler to copy the entire source folder here? We will only copy the published artifacts regardless

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was attempting to follow this multi-stage approach https://docs.microsoft.com/en-us/visualstudio/containers/container-build?view=vs-2019&WT.mc_id=visualstudio_containers_aka_containerfastmode

But I now realise the Dockerfile doesn't include a nuget package layer. I'll push an update that fixes that.

imagePullPolicy: Always
image: <REGISTRY_NAME>/yarp-controller:<TAG>
imagePullPolicy: IfNotPresent
image: yarp/yarp-controller
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sadly we can't check in a reference to your image here for security reasons

- name: yarp-proxy
imagePullPolicy: Always
image: <REGISTRY_NAME>/yarp:<TAG>
imagePullPolicy: IfNotPresent
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Out of curiosity, what's the significance of changing this policy? Wouldn't a cached image be used if one exists regardless?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Always will first query public feeds (e.g. Docker Hub, ACR, etc.) before checking locally.
When building and deploying locally, it's preferable to check locally first, before falling back to a public feed.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't this mean that if the image on a public feed is updated, you would not see changes locally?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For repeatability, it is better to choose when to update which versions of images are being run inside your cluster.
This ensures that you "know" exactly what is running inside your cluster. Think secure supply chain, image scanning pipelines, etc.

@dpbevin dpbevin force-pushed the dev/bevo/fixup-dockerfiles branch from fed41cb to 00e1789 Compare October 22, 2021 21:16
Copy link
Copy Markdown
Member

@MihaZupan MihaZupan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@MihaZupan MihaZupan merged commit d3a185a into dotnet:main Oct 25, 2021
@dpbevin dpbevin deleted the dev/bevo/fixup-dockerfiles branch November 17, 2021 20:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Dockerfiles not working

2 participants