I have a container building in gitlab and registering itself with the gitlab custom registry. Inside this container is a command that runs a very long time. I would like to somehow deploy this container to azure, and only kick off this long running process inside a new container instance on demand from an administrative api service. I don't want the container running all the time, only for the time it takes to run the command.
I was thinking that this admin api could be a classic http rest api service hosted under Azure "App Services", or possibly using the new "Function Apps" feature of Azure.
In my research, I found that using the azure cli commands, I can start a container like so:
az container create \
--resource-group myResourceGroup \
--name mycontainer2 \
--image microsoft/aci-wordcount:latest \
--restart-policy OnFailure \
--environment-variables NumWords=5 MinLength=8
https://learn.microsoft.com/en-us/azure/container-instances/container-instances-environment-variables
I would like to do this from the admin api, preferably using what looks to me like the official Azure npm package located here:
https://www.npmjs.com/package/azure
Ideally, it would be a single command to create and start the instance, being able to set the environment variables like this example at the launch of the container is important to me. I'm not interested in moving all my code over into Azure, I would like to continue using gitlab for the source code and container registry but if there is some reason I have to switch to using the Azure container registry, I need a way to somehow move the container registration over there using the gitlab ci yaml.
In all my searching, I couldn't find any way to do this but the closest documentation I found was here:
https://learn.microsoft.com/en-us/javascript/api/azure-arm-containerservice/containerserviceclient?view=azure-node-latest
At the current time there is no way to officially do this from the api, maybe in the future there will be
Related
I have created a clamav container instance (mkodockx/docker-clamav:alpine) within Azure but every few days it tends to be recreated by itself pulling the image over and over again, as you can see in the screengrab.
Is something wrong? Why would it be doing this?
I also have an Azure App Service which makes calls to the container instance over port 3310 but every few days it can't reach it...
What is going on? Why can't it be reached? I reached out to Azure support but they were super unhelpful
I'm no expert in containerization so please dumb it down for me :)
Thanks
I would start with setting the Restart Policy of the Azure Container Groups
There are three policies for the Azure Container Groups :
Never
Always
On Failure
The default policy is Always
You could change the Policy and observe the output in your case :
You could use the below commandlet to change the Restart Policy :
az container create \
--resource-group <myResourceGroup> \
--name <mycontainer> \
--image <IMAGE> \
--restart-policy OnFailure #(or Never)
Reference
I have a Web app running on Linux which is deployed from Docker Container.
Container comes from Azure container registry and was defined when I created the web app.
When I try to set my release pipeline to deploy to this web app, it doesnt offer me this choice.
When I set my subscription and Web app on Linux, I only see web apps that are deployed from code. My web app from docker container is not in the list in the App Name select:
I tried to do this manually using Azure PowerShell. I have set up local connection and trying to test the deploy but it doesnt work.
I have downloaded the repository locally as a zip file and I am trying to deploy it from this local zip file to the Web app on Azure. I try to deploy it from Powershell:
$webapp = Get-AzWebApp -ResourceGroupName "MyResourceGroup" -Name "my-container-app"
$path = 'C:\temp\repository.zip'
Publish-AzWebApp -WebApp $webapp -ArchivePath $path -Force
I am using Publish-AzWebApp command.
This command goes without an error, I also tried without -Force parameter, and with -AsJob parameter.
Everytime the command is executed successfully, but when I check my web app there is nothing deployed there. If I try this exact procedure with web app that is not from container, but from code than it works. By code/container I mean this setting that you choose when creating web app:
Currently I am using docker image that is also used by Azure as default so it should be the same Debian. I need to use it because I want to set some things differently in my web app, so I want to have my own system on web app, but deploy code from Devops to it.
However it seems that this type of web app is not supperted for deploy - nether from Devops gui, nor from Azure CLI. Can I somehow deploy my code on a web app that is running on my custom docker image?
PS: One option is to use the agent in Devops pipeline, compile a docker image from it and publish it with my code to the Azure container repository, from which it can be used form my web app. Problem is that you can only choose from 2 Ubuntu versions as an agent for build pipeline and I dont want that.
Any help is appreciated, thanks
For your requirements, first of all, you need to know the Web App on Linux and Web App for Container are two different resources, so it does not list your app deployed from the docker image. And second, when you use the docker image, it means you need to create a new image when your code change. So it does not support that create the Web App from the docker image and then publish the code from the DevOps.
The option that you think is right. Don't worry about the OS, you can use the Azure CLI command to create the docker image and push it to the Azure Container Registry directly:
az acr build -t image_name:tag -r acr_name source_code_path
And then deploy the image from the ACR to the Web App. In this way, the DevOps agent just use to run the task, not for the creation of the docker image.
I'm using the Azure resource "Web app for containers" with a Linux docker image. I would like to use docker commands such as "docker inspect" but I'm not sure how this is possible. Via the Kudo interface this doesn't seem possible. I cannot even get the SHA256 hash of the image currently deployed. All I have is the initial docker run command executed by the app service itself.
Does anyone know how such operations can be executed with app containers in Azure ?
The Azure Web app for container is different from the container. It is a web app service when you create it. The difference is that it comes out from a container.
So you cannot execute a docker command to a web app. You can execute the command of the web app.
For example, if you want to check the container image, the command is az webapp config container show --resource-group groupName --name webName and the result like this:
For more details about Web app command, see Web App commands.
Quite me to this stuff, but I seem to miss something. I push an image to a private Azure registry and spawned a container instance right through the portal. Works like a charm. Now I changed something, pushed again and... What do I do? Kill and delete the instance and recreate? Everytime?
Br,
Daniel
Another good way to do this these days is to restart the container. You can run the Azure CLI command or do it from the front end.
az container restart -g="XXX" -n="XXX"
An added benefit is that your public IP stays the same.
https://learn.microsoft.com/en-us/cli/azure/container?view=azure-cli-latest#az-container-restart
You don't need to delete every time! Just make sure your docker tag is always the same then after pushing you can just restart your app service.
tag example
docker tag myimage image.azure.ac/myimage:latest
latest in this case it's my tag
Generally - yes. But you can create a webhook that will invoke something when a new image is pushed to the repo. That can act as a way to automate redeployment.
possible solution is to use Azure Managed DNS name for container:
az container create -n helloworld --image microsoft/aci-helloworld -g myResourceGroup --dns-name-label mycontainer
this way your dns name will always stay the same
Just restart the container using the portal like the following:
Or use the following Azure CLI command if the container is on a running state.
az container restart --name <container_instance_name> --resource-group <RG_name>
To confirm the successful pull/update of the image, you should see a pull event before the start event near the time you restarted, like the following:
Our previous GitLab based CI/CD utilized an Authenticated curl request to a specific REST API endpoint to trigger the redeployment of an updated container to our service, if you use something similar for your Kubernetes based deployment this Question is for you.
More Background
We run a production site / app (Ghost blog based) on an Azure AKS Cluster. Right now we manually push our updated containers to a private ACR (Azure Container Registry) and then update from the command line with Kubectl.
That being said we previously used Docker Cloud for our orchestration and fully integrated re-deploying our production / staging services using GitLab-Ci.
That GitLab-Ci integration is the goal, and the 'Why' behind this question.
My Question
Since we previously used Docker Cloud (doh, should have gone K8s from the start) how should we handle the fact that GitLab-Ci was able to make use of Secrets created the Docker Cloud CLI and then authenticate with the Docker Cloud API to trigger actions on our Nodes (ie. re-deploy with new containers etc).
While I believe we can build a container (to be used by our GitLab-Ci runner) that contains Kubectl, and the Azure CLI, I know that Kubernetes also has a similar (to docker cloud) Rest API that can be found here (https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster) — specifically the section that talks about connecting WITHOUT Kubectl appears to be relevant (as does the piece about the HTTP REST API).
My Question to anyone who is connecting to an Azure (or potentially other managed Kubernetes service):
How does your Ci/CD server authenticate with your Kubernetes service provider's Management Server, and then how do you currently trigger an update / redeployment of an updated container / service?
If you have used the Kubernetes HTTP Rest API to re-deploy a service your thoughts are particularly value-able!
Kubernetes Resources I am Reviewing
How should I manage deployments with kubernetes
Kubernetes Deployments
Will update as I work through the process.
Creating the integration
I had the same problem of how to integrate the GitLab CI/CD with my Azure AKS Kubernetes cluster. I created this question because I was having some error when I tried to add my Kubernetes cluester info into GitLab.
How to integrate them:
Inside GitLab, go to "Operations" > "Kubernetes" menu.
Click on the "Add Kubernetes cluster" button on the top of the page
You will have to fill some form fields, to get the content that you have to put into these fields, connect to your Azure account from the CLI (you need Azure CLI installed on your PC) using az login command, and then execute this other command to get the Kubernetes cluster credentials: az aks get-credentials --resource-group <resource-group-name> --name <kubernetes-cluster-name>
The previous command will create a ~/.kube/config file, open this file, the content of the fields that you have to fill in the GitLab "Add Kubernetes cluster" form are all inside this .kube/config file
These are the fields:
Kubernetes cluster name: It's the name of your cluster on Azure, it's in the .kube/config file too.
API URL: It's the URL in the field server of the .kube/config file.
CA Certificate: It's the field certificate-authority-data of the .kube/config file, but you will have to base64 decode it.
After you decode it, it must be something like this:
-----BEGIN CERTIFICATE-----
...
some base64 strings here
...
-----END CERTIFICATE-----
Token: It's the string of hexadecimal chars in the field token of the .kube/config file (it might also need to be base 64 decoded?). You need to use a token belonging to an account with cluster-admin privileges, so GitLab can use it for authenticating and installing stuff on the cluster. The easiest way to achieve this is by creating a new account for GitLab: create a YAML file with the service account definition (an example can be seen here under Create a gitlab service account in the default namespace) and apply it to your cluster by means of kubectl apply -f serviceaccount.yml.
Project namespace (optional, unique): I leave it empty, don't know yet for what or where this namespace can be used.
Click in "Save" and it's done. Your GitLab project must be connected to your Kubernetes cluster now.
Deploy
In your deploy job (in the pipeline), you'll need some environment variables to access your cluster using the kubectl command, here is a list of all the variables available:
https://docs.gitlab.com/ee/user/project/clusters/index.html#deployment-variables
To have these variables injected in your deploy job, there are some conditions:
You must have added correctly the Kubernetes cluster into your GitLab project, menu "Operations" > "Kubernetes" and these steps that I described above
Your job must be a "deployment job", in GitLab CI, to be considered a deployment job, your job definition (in your .gitlab-ci.yml) must have an environment key (take a look at the line 31 in this example), and the environment name must match the name you used in menu "Operations" > "Environments".
Here are an example of a .gitlab-ci.yml with three stages:
Build: it builds a docker image and push it to gitlab private registry
Test: it doesn't do anything yet, just put an exit 0 to change it later
Deploy: download a stable version of kubectl, copy the .kube/config file to be able to run kubectl commands in the cluster and executes a kubectl cluster-info to make sure it is working. In my project I didn't finish to write my deploy script to really execute a deploy. But this kubectl cluster-info command is executing fine.
Tip: to take a look at all the environment variables and their values (Jenkins has a page with this view, GitLab CI doesn't) you can execute the command env in the script of your deploy stage. It helps a lot to debug a job.
I logged into our GitLab-Ci backend today and saw a 'Kubernetes' button — along with an offer to save $500 at GCP.
GitLab Kubernetes
URL to hit your repo's Kubernetes GitLab page is:
https://gitlab.com/^your-repo^/clusters
As I work through the integration process I will update this answer (but also welcome!).
Official GitLab Kubernetes Integration Docs
https://docs.gitlab.com/ee/user/project/clusters/index.html