Once a gitlab instance is set up to use kubernetes and auto-deploy, all that is left is setting your environment variables whenever you create a new project. Let’s deploy an app.
We could technically just deploy now, and we’ll be given a review subdomain on our wildcard kubernetes host we set earlier (some-auto-generated-review-environment.k8s.80pxtesting.com). Let’s actually deploy a web page to the domain 80pxtesting.com since we haven’t put anything on the root domain yet. We’ll only deploy to this domain when we’re going to production, and use review URL’s for any merge requests.
Quick question… How does gitlab know how to deploy my application to kubernetes? It’s a good question. There are multiple ways. You will have to learn more about it here to determine which is the best for your project.
Here are a few ways you can auto deploy:
.staticfile to the root of your project to deploy the contents of that folder to a web server
Dockerfilethat builds and runs your deployment, which also uses and exposes port
Use Herokuish to intelligently determine how to build your application
package.jsonHerokuish will attempt to use Node to run
npm run buildon the build step, and
npm startfor the deploy step
We will do a simple
.static file for now. Let’s create a project named after the website we’re going to deploy to. This helps us reference the kubernetes deployment later because they are based on the repository name.
+ button on the top of gitlab, and click
Create blank project.
Add the name, and make sure it is under the
softwarecompany group. Adding the actual URL of the app in the description is nice to have clickable as well.
First, let’s add the DNS record for that domain to point to the cluster’s load balancer IP.
Then, we’ll add environment variables so our project knows which URL to use.
@ DNS record to point to the root domain
Add the auto deploy environment variable to set up the URL for this project.
When you’re on the project’s main page in Gitlab, go to
CI / CD.
Variables section, and add these two variables:
TEST_DISABLEDjob, as we want this to run on all repository branches for now.
.staticfile deployments do not support tests.
POSTGRES_DISABLEDto disable creating a postgresql pod and spawning a data volume.
We’re going to edit this repo using the
Web IDE button next to the blue
Clone button on the main project page.
You can also use
git to manage the repository using your SSH but that is a tutorial for another day.
Our end goal will be the same— changing the files in the repo. Gitlab will automatically detect the changes and use
Auto Devops like it suggests in the blue banner by detecting one of their many deploy methods.
Web IDE, it should look like this.
Now simply add an empty file (The document icon with the
+ symbol) called
And I’ll also add a barebones HTML page called
index.html. We will make an adapted version of index.html on the HTML5 Boilerplate project.
<!doctype html> <html lang="en"> <head> <meta charset="utf-8"> <title>80pxtesting.com</title> <meta name="description" content="kubernetes served website"> <meta name="viewport" content="width=device-width, initial-scale=1"> </head> <body> <!-- Add your site or application content here --> <p>Hello from kubernetes.</p> </body> </html>
Hello from kubernetes.
Commit the changes and push it to a new branch. Also, start a new merge request. (These are the default options)
This is good practice to test your new auto deploy environment on a review branch, then you can merge it to the main branch and it will deploy to production.
After you hit commit, you will be brought to the new merge request screen. You can add a description and other information to your merge request.
Hit submit merge request to finish.
You will see your application running it’s auto deploy steps. There are a few stages, and each one can have a few jobs.
You can see the app building the docker image and pushing it to the registry (based on on the
.static file) in the build stage.
The test stage has a few jobs underneath it:
In a few minutes, this should be done. Your pipeline looks like this.
To find your review environment you can either:
Merge Requestthe review environment is associated with
Operationson the left
Here is the
Environments page after our build and deploy:
Now you can click the
Open live environment button.
And we’ll see our website at the automatically generated URL.
Alright! Last thing to do now is push this to production. We like these changes, so let’s hit merge
Now we have merged that branch, and a new build will happen for our main branch.
If everything was set up correctly, we can now go to the production URL, which we specified in our environment variables.
We did it! We deployed an app to kubernetes using gitlab. We used free software to do this, Big thank you to Gitlab, and all the umbrella software and developers that includes.