How To Deploy Pimcore on the Alibaba Cloud

Alibaba Services

I’ll discuss each of the cloud services I used and how I configured them. Each cloud service is broken up into its own section. As a quick reference, I used:

• Container Registry - Storing images
• ApsaraDB for RDS - Managed Database Service
• ApsaraDB for Redis - Our cache service
• SSL Certificates - For managing SSL Certs
• NAS File System - Used for persistent storage of files
• Serverless Kubernetes - The puppet master for running the application

Container Registry

I started with Alibaba’s container registry, which is an environment used for storing Docker images. I used Github as a source control system from which the images would be built. I connected the following Git branches with the associated Docker Tags.

Docker setup

First of all, I needed to ensure that the Dockerfile was in the root of the repository.

At this point, it seems like the easiest way to get the builds running is to put the Dockerfile in the root of the repository and adjust all ADD/COPY commands to be relative to this path.

Configuring the Settings

The ideal setup within Alibaba for these builds involves the following: I had to set the automatically build images when code changes property to on. Similarly, I had to make sure that I was using servers that are deployed outside of Mainland China to ensure better performance:

Also note that after the cluster is installed, you will need to set up triggers. When a container image finishes building, these will trigger the redeployment of our cluster.

ApsaraDB for RDS

For the local MySQL server, I used ApsaraDB for RDS.
he Pimcore setup requires the following settings:

• Database Engine: MySql 5.7
• Edition: High Availability (Alibaba Cloud claims this covers > 80% of business usage
• Storage Type: Local SSD
• Instance Type: rds.mysql.s1.small – 1 Core, 2GB RAM, 300 Max Connections

It’s important that your subscription is set for auto-renewal; otherwise, it’s easy to lose the instance accidentally.

Whitelist

The whitelist is similar to AWS’s security groups. Make sure to add the IP of any service that needs to access the database to this whitelist.

InnoDB Large Prefix

Pimcore requires this setting to be on. Edit it under the instance Editable Parameters. Finally, be sure to use utf8mb4 when creating the database, to be compatible with Pimcore.

AbsaraDB for Redis

I used ApsaraDB for Redis as Pimcore’s caching service. It is important to set it up in the same zone as all other services and configure whitelist settings for it.The following settings worked fine in a low traffic setup - though you may need to adjust accordingly:

• Edition: Community
• Version: Redis 5.0
• Architecture Type: Standard *
• Instance Class: 1G (note: this goes a long way with a cache!)

SSL Certificates

It is more cost-effective to purchase an SSL certificate externally and then upload it to Alibaba. You will need to deploy the certificate to SLB in the correct application region:

Very Important: Be sure to keep a record of the certificate id; this will be needed later when you’re setting up the SLB in the cluster. Note that this is not the same id that appears on the details pane, as shown below:

Determining the proper certificate ID took some effort, but the details can be found in the full post here.

NAS File System

I used the Alibaba NAS as our file system for Pimcore. It provides a true NFS file system, which makes clustered deployments possible. This is essentially our Docker Volume.

• Create your files in the same region as all other files.
• Set your subscription to auto-renew
• I suggest the following settings:
  • Storage Type: Capacity Type (this seemed adequate for our performance needs)
  • Protocol: NFS
  • Capacity: Start at 100GB

Next, we will also want to add a mount target. In my case, I chose to create a “root” level mount point and treat the disk much in the same way that I would a physical disk.

Serverless Container Service

The Serverless Container Service serves to create other Alibaba cloud services. You can monitor these services inside the Alibaba portal and manage them directly through the cluster. Changes made will temporarily persist; however, the cluster is essentially the puppet master for the system. You can make temporary changes at the individual service level, but the cluster will eventually overwrite them.

A couple of helpful terms in Kubernetes and Alibaba vernacular:

Pods - Elastic Container Instance

Services - Server Load Balancer

To remote into the container, we can look it up in the Elastic Container Instance section and use the web UI.

Configuring the Container

Under Container Configuration, we can set which environment variables are passed into the container. This is also where we will set up the NAS network mount points. The full details can be found in the full article.

Pulling the Docker Image

To configure our containers, we pull our image from the registry we set up earlier, like so:

Redeployment Triggers

This is the heart of continuous deployment. We need to create a redeployment trigger to hook into the container registry and have the registry tell the cluster when a new image is ready.

When we are back in the container registry side, we can take this link address and put it into the trigger, like so:

Server Load Balancer

The best approach for modifying the SLB (bandwidth and cert-id) is via SLB annotations rather than directly modifying the SLB. There is important information in the full article regarding this.

Closing Notes

Throughout the entire process, there are several tips to keep in mind:

• Remember to set up all services and files in the same region/zone for optimal performance.
• Set your services to auto-renew when provisioning services.
• Due to the similarities between Alibaba Cloud and AWS, you can draw on AWS experience if you hit roadblocks.