I am trying to pull and push images between Docker Desktop and Azure and Visual Studio 2019.
currently I can push from VS2019 by Publish option and I can push to Docker and Azure Container Registry.
How do I pull from Azure to Docker? I believe there is an issue with security accounts between the 2 systems. After all, my Docker account is not my Azure account. I came across this article
https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal
which contains a script. Is this the right article to solve my problem? I made a copy of the script but I am struggling to run it. If I save it to assignpermissions.sh file and run wsl ./assignpermissions.sh it complains that az does not exist.
So
Is that the right article to help me (eventually) pull and push between Azure and Docker?
How do I run the script when calling az is causing an error?
Any other things I need to watch out for in the next step?
Log in to a registry
There are several ways to authenticate to your private container registry.
Azure CLI
The recommended method when working in a command line is with the Azure CLI command az acr login. For example, to log in to a registry named myregistry, log into the Azure CLI and then authenticate to your registry:
az login
az acr login --name myregistry
Azure PowerShell
The recommended method when working in PowerShell is with the Azure PowerShell cmdlet Connect-AzContainerRegistry. For example, to log in to a registry named myregistry, log into Azure and then authenticate to your registry:
Connect-AzAccount
Connect-AzContainerRegistry -Name myregistry
You can also log in with docker login. For example, you might have assigned a service principal to your registry for an automation scenario. When you run the following command, interactively provide the service principal appID (username) and password when prompted. For best practices to manage login credentials, see the docker login command reference:
docker login myregistry.azurecr.io
Both commands return Login Succeeded once completed.
Note: You might want to use Visual Studio Code with Docker extension for a faster and more convenient login.
Tip: Always specify the fully qualified registry name (all lowercase) when you use docker login and when you tag images for pushing to your registry. In the examples in this article, the fully qualified name is myregistry.azurecr.io.
Push the image to your registry
Now that you've tagged the image with the fully qualified path to your private registry, you can push it to the registry with docker push:
docker push myregistry.azurecr.io/samples/nginx
Pull the image from your registry
Use the docker pull command to pull the image from your registry:
docker pull myregistry.azurecr.io/samples/nginx
Related
Since Docker Hub only allows 1 private repo, I wonder if there is any way to use Github or Gitlab, etc., to download the images? for instance:
FROM git#github.com/username/repo
...
...
...
Very easy with an account on gitlab.com. GitLab provides a Docker registry linked to projects and you can have unlimited private projects:
Create a project my-docker-project
Go to Package and Registries > Container registries, you should see a few commands to access your registry
Connect your machine to this registry using a command like:
# Will prompt for login/pass
docker login registry.gitlab.com
You'll need an access token or deploy token with read_registry and write_registry scopes. You can generate one via your profile Preferences > Access token. Login is the token name and password the secret token provided.
You can now push Docker images with commands such as:
# Push an image
docker push registry.gitlab.com/YourUsernameOrGroup/my-docker-project
# Push an image on a sub-path
docker push registry.gitlab.com/YourUsernameOrGroup/my-docker-project/myimage
You can then use the image in a Dockerfile by referencing its URL such as:
FROM registry.gitlab.com/YourUsernameOrGroup/my-docker-project
# ...
Of course the machine from which you build must be authenticated on related GitLab registry using docker login command above (or the project must be public)
both have excellent package registry services
For GitHub GPR
For GitLab GCR
Both have excellent features like use it directly from Dockerfile as you want for example.
I have a public example, you can check it in Github with node.js which uses GPR to store the build image/package.
I have a private GitLab project with a pipeline for building and pushing a Docker image. Therefore I have to authenticate to GitLab's Docker registry first.
Research
I read Authenticating to the Container Registry with GitLab CI/CD:
There are three ways to authenticate to the Container Registry via GitLab CI/CD which depend on the visibility of your project.
Available for all projects, though more suitable for public ones:
Using the special CI_REGISTRY_USER variable: The user specified by this variable is created for you in order to push to the Registry connected to your project. Its password is automatically set with the CI_REGISTRY_PASSWORD variable. This allows you to automate building and deploying your Docker images and has read/write access to the Registry. This is ephemeral, so it’s only valid for one job. You can use the following example as-is:
docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
For private and internal projects:
Using a personal access token: You can create and use a personal access token in case your project is private:
For read (pull) access, the scope should be read_registry.
For read/write (pull/push) access, use api.
Replace the <username> and <access_token> in the following example:
docker login -u <username> -p <access_token> $CI_REGISTRY
Using the GitLab Deploy Token: You can create and use a special deploy token with your private projects. It provides read-only (pull) access to the Registry. Once created, you can use the special environment variables, and GitLab CI/CD will fill them in for you. You can use the following example as-is:
docker login -u $CI_DEPLOY_USER -p $CI_DEPLOY_PASSWORD $CI_REGISTRY
and Container Registry:
With the update permission model we also extended the support for accessing Container Registries for private projects.
Version history
Your jobs can access all container images that you would normally have access to. The only implication is that you can push to the Container Registry of the project for which the job is triggered.
This is how an example usage can look like:
test:
script:
- docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
- docker pull $CI_REGISTRY/group/other-project:latest
- docker run $CI_REGISTRY/group/other-project:latest
I tried the first and the fourth way and I could authenticate.
Question
What are the pros and cons? I guess the third way is for deployment only, not for building and pushing. Same could be for the second way. Is that right?
And why is the fourth way not listed in the other documentation? Is that way deprecated?
I prefer the fourth option. A note: "If a user creates one named gitlab-deploy-token, the username and token of the deploy token is automatically exposed to the CI/CD jobs as CI/CD variables: CI_DEPLOY_USER and CI_DEPLOY_PASSWORD respectively.
When creating deploy token, you can grant permission read/write to registry/package registry.
The CI_REGISTRY_PASSWORD is ephemeral so avoid using it if you have multiple deploy jobs (which need to pull private image) run parallel.
I believe the differences are just about user skill and permissions.
The first way anyone can do since the variables are automatically present in a running job.
Second, anyone, with any permissions, can create a personal access token (but has an extra step compared to 1 to create the access token).
Third, someone with the correct permissions could create a deploy key. Deploy keys don't give access to the API like personal access tokens can, and only have permission to pull/read the data in the repository, they cannot write/push.
Fourth option, it allows you to both read/pull container images from the registry, but it also allows you to push to the registry. This is helpful if you have a CI step that builds an app in an image, or anything else where you're generating a container image and want to push it into the registry (so another step in the pipeline can pull it down and use it). My guess is that this option isn't listed with the others since it's meant for the building of container images. You probably could use it like any of the others though.
We have ansible configured to deploy our various applications on IIS environment. I am trying to create a docker image of deployed applications so that I can just start up containers as we need for testing and otherwise.
I am planning to build on the Windows IIS image, start the container on azure, run our ansible to install everything on the server, then save the image on container.
I cannot find any documentation on how I can docker commit the container image into our private azure container registry.
Is it possible?
If you have an existing Docker registry in azure you should be able to use the az acr login --name myregistry command to authenticate to it https://learn.microsoft.com/en-us/azure/container-registry/container-registry-get-started-docker-cli. Make sure you have a registry created for the container image you want to push up.
Next, you can run the container in azure and do all the installation you want. SSH or RDP into the instance in Azure that is running this container. Now run docker ps and find the container id for the correct container. Next, use docker commit <container id> myregistry.azurecr.io/samples/nginx.
Then, just docker push myregistry.azurecr.io/samples/nginx
Also not sure what your use case is, but starting a container in order to modify and commit it in that way seems like an atypical use case for Docker since the build isn't reproducible via the Dockerfile. Looks like there are ways to replace Dockerfiles using Ansible playbooks with something like ansible-containers https://docs.ansible.com/ansible-container/ so you might want to take a look at that(I've never used this tool).
I have a jenkins job and we build our docker containers using the docker build and publish plugin.
Most of the containers are built and published to our private repos in dockerhub without any issues. They inherit images from public repositories and work fine.
However we have noticed that dockerfiles that contains
FROM private_repo:tag
fail because docker cannot find the image in our private repo. We have provided credentials via the docker registry credentials option but doesn't work. It simply says
"image not found"
at the end of the build.
If I login to our jenkins server and do docker login and then pull the image that works fine. This leads me to believe something is wrong with the credentials when it is pulling from the private repo. Has anyone encountered this or know the issue?
I have always run docker login -u $DOCKER_USERNAME -p $DOCKER_PASSWORD at the beginning of my docker build / docker push Jenkins jobs. Save the username/password as a Jenkins credential and you won't have to share it anywhere.
My aim is to show the portability of docker, and thus being able to export docker container images from the registry/repository to an external docker user.
I can perfectly pull the image from the machine with ICE CLI installed, and authentication (ice login passed), but if I use an other machine, the command docker pull registry-ice.ng.bluemix.net/ibmnode or docker pull registry-ice.ng.bluemix.net/kapi/nginx-test, I get the same result : authentication required.
My question is : is it possible to allow some docker images to be available for everyone, without authentication ?
I can obviously pull the image from the machine with ice logged in, and then re-export/push it, but it is not the easiest way.
Has anyone an idea, on how to do this ?
Thanks for reading
As you discovered, IBM Containers currently requires a Bluemix authentication token when connecting to the Bluemix container registry. There is not a public registry where anyone can pull images.
But your idea is interesting and we could look into providing some public images on a public registry. For now, you will need to sign in.