The cloud container is a cloud computing model in the service provider by creating hardware facilities and some tools, increasing the speed of software development, and solving the developer’s concern about the infrastructure required by the product.
In this article, we will examine the concept of Build and how to use it, its types and components, and its definition.
Prerequisites
The only prerequisite for this guide is to have an ArvanCloud account and access to the cloud container. After logging in to the user account, go to the profile section, create a new API KEY in the API KEYS tab, and save it somewhere.
To complete the steps of this article, you need to use the ArvanCloud command line. Download the command line using this link (put it in your PATH if required) and log in through the command line:
Then paste the API KEY you received from the site below.
What is Build?
The Build is actually the process of converting an input, such as a written code, or an online store written in PHP, to an output element, such as a container image, for example, the final image made for use in Deployment, which is defined by buildConfig. Build has different strategies, of which we will only focus on Docker in this article.
Creating Build
To create Build, you need to enter the required information in yaml format in a file and then submit it to the ArvanCloud Container Service through the command line. For example, the following code snippet contains all the buildConfig settings for a code written in Python.
Note that this article assumes that the corresponding Dockerfile is available next to the written code.
Note: indentation is vital in yaml files, and the slightest shift can cause an error or unwanted settings to be returned.
spec.runPolicy: This field specifies how Build processes should be executed. This value equals serial, so the following process is not completed before a build is completed.
spec.triggers: This field specifies how the process should be executed. In this example, the Build process will be performed if the code is pushed in the relevant Repository to the address “https://gitlab-example-project.apps.ir-thr-mn1.arvan.run/example/python.git” specified by spec.source field. To do this, you need to define a webhook in Gitlab. This Webhook requires a Secret specified by the field spec.triggers.gitlab.secretRefrence.name, and how to create it will be described below.
spec.source: specifies the code Repository address.
spec.output.to.name: The name of the final Container Image created at the end of the Build process. This name specifies to which Registry the generated image should be sent.
spec.source.sourceSecret.name: The Secret name Build needs to connect to Gitlab and get the code.
spec.output.pushSecret: Here, a Secret should be assigned, which includes information about connecting to the Docker Registry.
spec.resources: Since the Build process is executed by a Pod, it is necessary to specify the resources required by this Pod. Note that this Pod is run temporarily, is deleted at the end of the process, and after successful execution, its state changes to Completed. Therefore, it does not consume resources until the process is executed again.
Enter and save the above lines in a file called Build.yaml. Then submit your Build to the ArvanCloud Container Service through the command line with the following command.
Then, with the following command, you can understand the status of your Build and its execution on the ArvanCloud platform.
The output will be similar to the following:
Creating Secrets
The Secret is actually one of the main components, which is used to store data like Passwords.
In this system, as mentioned above, three types of Secrets are being used: a Secret for use in Webhook, another for storing connection information to a personal Docker Registry, and the third Secret to access the Build process to the private Repository available on your personal Gitlab.
Creating the Secret Related to Webhook
To create a webhook Secret for your personal Gitlab, type the following command in the terminal:
Here put <secret value> equal to whatever you want (here, we will put this value equal to secretvalue1). This value will be used later in the webhook set in Gitlab.
Building a Secret Related to Build Access to Personal Gitlab
Since your code is in a private Repository, it is necessary to give access to the Build process to receive and start your code. In this regard, it is sufficient to enter the following commands.
Note: In the above Secret, the kubernetes.io/basic-auth type is used to store the User and Password.
Creating a Secret Related to Docker Registry
To create your own private Docker Registry connection Secret, type the following command in the terminal:
Adding Webhook to Gitlab
To add a webhook to Gitlab for a trigger to run when the code is pushed, enter the following command in the terminal to get the webhook URL for Gitlab.
In the output, the Webhook section of GitLab will be the Webhook address as below.
Now you need to copy the URL (replace the < Secret> value with the secret value set in the previous sections (here secretvalue1)) and add it to your project in your personal Gitlab as described below.
First, log in to your Gitlab. Then, build your project. Then, go to settings > webhooks from the left menu of the project. Here, copy the webhook URL you got from the previous section, enable the Push tick, and then save.
Now you can push your code to your own Gitlab after the desired changes. Meanwhile, the Build process should start.
With the following command, you will be informed about the build status. After successfully completing the process, the created Container Image will exist in your personal Docker Registry.
Note that the Push Webhook may not be sent if you are using gitlab.com or github.com due to network problems. (There should be no problem getting the code)
Running The Build Process
As stated in the example, Gitlab webhooks (as well as Github or Bitbucket) can start the build process when the code is pushed into the Repository (or other options available in Gitlab settings), and the process begins automatically. You can also run a build process manually with the following command:
Which should be placed instead of <build-name>, the name of the created buildconfig.
When the build process starts, it spawns a Pod, and you can find out the status of this Pod by running the following command. You will also be able to read the Log related to this Pod to fix it if an error occurs.
When the Build status of the Pod reaches Complete, the process has been completed successfully.
For more information, you can refer to the OKD documentation.