ArvanCloud Cloud Platform will deliver hardware facilities and different tools to enhance the software development speed and take care of developers’ demands about products’ required infrastructures. This article will define deployment, its components, and its application in Arvan Cloud Storage. The Arvan Cloud deployment concept is similar to Kubernetes.
Arvan Cloud Deployment Requirements
The only requirements to get started are ArvanCloud User Account and ArvanCloud Cloud Platform service.
- Go to: arvancloud.ir, sign in/up.
- Click on: Profile name > API Keys.
- Create a new API key, and Save it.
Please note that ArvanCloud CLI is needed for the steps above. Download the command line (place it in the PATH if necessary) and use the command below to login. Then add the created API key.
What Is Deployment in PaaS?
Deployment (deploy) is one of the main parts of the Arvan Cloud Storage service, and as a useful modality will manage the pods’ statuses. It is possible to define the pods separated from the deployment and add them to Arvan Cloud Storage. If a pod is defined separated from deployment, it cannot be used in production systems. If a problem occurs and deletes the pod, it will not return to the administrative mode. And for that, a modality such as a deployment is needed to ensure that pods definitions are applicable and know the required numbers.
Create a Deployment
To create a deployment, save the data in a YAML file, then use the command line to add it to Arvan Cloud storage. The following example is the Nginx service deployment.
Tips: Note that the indentation is important for YAML files. If ignored, unwanted settings and errors will occur.
Here is an explanation of the related fields:
- Kind: This will define the nature of the deployment. It can include values like Pod, Deployment. Service and StatefulSet. They can have similar values as Kubernetes. In the example, the deployment is defined, and the value is based on it.
- Metadata.name: It determines the name of the deployment.
- Spec.replica: This will specify the number of pods a deployment applies/manages. Each pod will be defined by spec.template.spec field. The spec.replica will specify the number of running pods (similar) based on the definition.
- Spec.selector.matchLabels: Deployment will use the specific value of this field to know which pod should be managed. This field’s value must be based on key: value, and similar to spec.template.metadata.labels value. In this example, the app: Nginx value is used.
- Spec.template.metadata.labels: This field will assign key: value labels to create pods. Generally speaking, Arvan Cloud Storage connections are based on labels and selectors. For that matter, it is important to be careful with these values.
- Spec.template.spec: This will specify the features of the pods a deployment is responsible for. The spec.template.spec.containers subcategory will determine the containers that will be applied to each pod.
- Spec.template.spec.containers.Image: It displays the docker image address that a pod will run.
- Spec.template.spec.containers.name: It will determine the name of specified containers in each pod.
- Spec.template.spec.containers.imagePullPolicy: It will specify when a docker image must be pulled. In the example, this field is equated as IfNotPresent, which is its default value. Whenever an image isn’t available on a node, this image will be used. Never and always are two other values of this field. “Always” means that the cloud storage will re-receive the image whenever the program is rerunning. It is recommended not to choose never. This way, the cloud storage will suppose the image is always available on the node and will not pull it.
- Spec.template.spec.containers.ports: It will specify the number of ports that are available from outside of the container.
- Spec.template.spec.containers.resources: This field will determine the number of resources a container needs for running. Adjusting these resources is obligatory in Arvan Cloud Storage. Be Careful with this field to avoid resource shortage and errors. This field is based on two categories, which are limits and requests. Each of them includes memory, CPU, and ephemeral-storage. In Arvan Cloud Storage, the limits and requests values must be the same.
The ephemeral-storage will determine the number of disks the container uses. Its saved data is not stable, and that means if the pod restarts, the data will be reset to default values, and the setting will change. If a stable disk is needed, use persistentVolumeClaim.
Enter and save the mentioned fields in an Nginx-deployment.yaml file, then use the command below in the command line, and add the deployment to Arvan Cloud Storage.
Use the command below to know about the deployment status.
The output will be as below.
In this output:
- Name is the name of the deployment.
- DESIRED will determine the number of pods run by this deployment based on its spec.replica field value.
- CURRENT shows the number of running pods at the time.
- UP-TO-DATE determines the number of updated pods to be delivered to DESIRED.
- AVAILABLE shows the number of working pods.
- AGE shows the amount of time the deployment is running.
Increasing Replica
One of the advantages of using cloud storage is the possibility of scaling the application. Suppose the number of Nginx requests is increasing, and a single Nginx will not handle all the requests. Arvan Cloud Storage makes it possible to add the number of Nginx. To do so, follow the instructions below.
Use the command below.
Once done, the number of Nginx will be increased to two. The get deploy command’s output is the same.
Tips: The deployments with persistentVolumeClaim are not scalable. Only one replica of them can be running. If it is necessary to scale a pod with persistentVolumeClaim, use stateFulSets.
The command below will show the running pods.
- Change the number of specified pods in spec.replica field place in the deployment configuration file. Change its value and add it to Arvan Cloud storage again.
- Use the command below to change the deployment setting on Arvan Cloud Storage directly.
This command uses the Arvan Cloud default editor to show the deployment setting in a YAML file. Apply the changes and save them. Once the editor is closed, the changes will be applied automatically.
Update Strategies
Applying new deployment changes will eliminate the last pods. The new deployment will create/run new pods. The change of strategy can happen in two ways:
- Recreate
- RollingUpdate
Recreate Strategy
The recreate strategy will eliminate the last pods and create new ones. If the Arvan Cloud storage deployment has persistentVolumeClaim it is necessary to use this strategy. To do so, use the same spec.strategy.type value for Recreate.
RollingUpdate Strategy
RollingUpdate is the default strategy used in deployment. IT will provide users with different settings to update the pods. The new pods will be created through this process, and the older ones will be eliminated over time. These settings include maxUnavailable and maxSurge fields. They are explained below.
- Spec.strategy.RollingUpdate.maxUnavailable:
This field will determine the maximum number of unavailable and inactive pods in the update process. The value of this field can be determined with a static number or percent. The value in percent will be based on the number of replicas.
- Spec.strategy.RollingUpdate.maxSurge:
This field will determine the maximum number of pods in the update process, which can be more than the number of specified replicas in deployment. The value of this field can be determined with a static number or percent. The value in percent will be based on the number of replicas.
The value of these two can not be determined as zero at the same time.
Here is an example of this strategy for Nginx deployment.
ReplicaSet
ReplicaSet is one of the main nature of cloud storage responsible for managing the replications, and pods. A deployment will create a replicaset automatically to manage the pods. Users are not connected to replicasets directly. Any new changes in the deployment setting will create a replicaset and eliminate the older one. These changes will be made automatically. It is recommended not to use the replicaset directly and use deployment instead. With Arvan Cloud storage, the users will not face any compilation, and everything will be managed thoroughly.
To learn more about this subject, check out the Kubernetes documents. This article is based on these references: