Quick start

Overall process

1. Open the Eco Cloud docker image repository
2. Create space
3. Add permissions to space
4. Push the image to the Eco Cloud docker registry
5. Create a docker registry credential
6. Create a domain name
7. Deploy application
8. Access to services such as Database and Redis/Memcached

Eco Cloud docker registry

The AppEngine(K8s) can use any docker registry to deploy applications. In order to speed up the image fetch speed and application startup speed, please use the Docker registry provided by the Eco Cloud.

Please contact an engineer from the Mi Eco Cloud support group to connect the Mi Eco Cloud. Open the Eco Cloud Docker registry. Generally speaking, a company will share a project. It is possible to create multiple users. If more than one project is required, a separate request can be made. In addition, the Eco Cloud docker repository only allows whitelist access and requires a fixed extranet IP.

If more than one project is required, a separate request can be made. In addition, the Eco Cloud docker registry only allows whitelist access and requires a fixed extranet IP.cnbj-repo.cloud.mi.comThe address of KSYun-Beijing 6 iscnbj6-repo.cloud.mi.com Combined with the company project name, the specific address of the image is (using the example of AWS-Beijing) cnbj-repo.cloud.mi.com/<company-project>/<image-name>:<image-tag>

Docker registry addresses

Create space

Log on to the Eco Cloud using an administrator account and switch to KSYun-Beijing 6. Next, add the following space resources in user management. The name should not include the company org name.

Then add the resource to the relevant roles.

Note

1. Currently, AppEngine(K8s) has opened the KSYun-Beijing, AWS-Oregon, AWS-Frankfurt, and AWS-Singapore regions, but add and modify operations can only be carried out in the KSYun region
2. After the space is created, the name is automatically appended to the company's org name

Add permissions to space

Log on to the Eco Cloud using an administrator account and switch to KSYun-Beijing 6. Next, add space permissions to roles in user management.

The resource is added to the appropriate role and given permissions for the role. The developer has read and write access; the auditor has only read access.

Build and test docker image locally

After an application is developed locally, the docker image is created. After testing, the image is pushed to the Docker registry on the Eco Cloud.

docker login cnbj6-repo.cloud.mi.com
docker tag myapp:1.0 cnbj6-repo.cloud.mi.com/myorg/myapp:1.0
docker push cnbj6-repo.cloud.mi.com/myorg/myapp:1.0

Files and logs

Do not store persistent files locally; backend services such as FDS should be used.

Logs are not written to local files and must be written to standard output or standard error output (STDOUT/STDERR) in order to be collected and analyzed by the logging system.

Best practices

Docker mirroring best practices

Create docker registry credential

Log on the Mi Eco Cloud, create a docker repository credential in "Secrets Management" on the products page of the AppEngine(K8s). The AppEngine will use this credential to pull the application docker image.

Click "Secrets Management" and then click "Create" in the upper right corner.

Make sure you select "Docker Repository Credential"

Create domain name

If the application provides web services externally, you need to bind your own domain name. Assuming the domain name for application's external services is app1.mydomain.com, create the domain name mydomain.com in "Domain Name Management V2"

Deploy application

Create an application

Click on "AppEngine(K8s)" on the product page to enter the application list page, then click "Create New Application" on the left to deploy the application. This uses the docker image and repository certificate created previously.

Note

Do not store persistent files locally, the log must be written to standard output or standard error output (STDOUT/STDERR).

Exposing external services

Exposing external services is optional, and can be done through either HTTP/HTTPS or TCP/UDP

HTTP/HTTPS method: The domain name created above is used here. In order to provide HTTPS service, it is also necessary to create Secrets for the TLS certificate type The IP whitelist is set to allow access to the HTTP/HTTPS service for the client IP address. This configuration follows the CIDR format. If multiple CIDRs are configured, use a comma split, for example, “111.111.111.0/24,222.222.222.222/32”; if not configured, all IP addresses are allowed.

TCP-UDP method:

Modify domain name pointers

Modify app1.mydomain.com pointers in the management console of the domain name provider

Proxy server IP list for external TCP/UDP

Health check

Health checks are optional. Providing health checks on two dimensions: service startup checks and service health checks

Service startup checks

Determines whether the container is started, accepts external requests

When the container has started, the services inside the container may not be ready. Using the configuration service startup check, external requests can only be accepted when the services inside the container are available. If the service detection fails to detect according to the set rules, the container is deleted and a replacement is created.

• Detection methods:

  • HTTP GET method: An HTTP Get request is performed on the specified port and the container IP address for the path. If the status code for the response is in the range [200, 400] range, the diagnosis is considered successful.
  • TCP Socket method: TCP check for container IP address for the specified port. If the port is open, the diagnosis is considered successful.
  • Container Command: Executes the specified command in the container. If the return code is 0 on exiting the command, the diagnosis is considered successful.

• Request parameters:

  • First wait time: Wait time for first health check, optional, default is 0.
  • Frequency: Detection frequency, optional, default is 10 seconds.
  • Timeout: Timeout waiting for a response. When a timeout occurs, we assume that the container can no longer provide services and restart the container, optional, default is 1 second.
  • Number of successful attempts. Number of consecutive successful attempts required to produce successful result, optional, default is 1 attempt.
  • Number of failed attempts. When a container startup fails or detection fails, the container will make more attempts until the limit is reached, optional, default is 3 attempts.

Service health checks

Determine whether the container has survived and can accept external requests

When the container is running, is it is detected that the container service is no longer available according to the set rules, the instance is removed from the service provision list so that it has no external requests; the container is deleted and a new container is created.

• Detection method: As with the service startup check, there are three detection methods.
• Request parameters: As with the service startup check, but the total number of successful attempts is 1, and this does not need to be configured on the interface.

Container exit settings

The container exit settings are optional and can be configured in [Application Management] - [Application Details] - [Container Exit Settings]

The container exit settings provide a graceful stopping function for the container. Before stopping the container, the services inside the container are given a certain processing time, preserving the execution scenario, and providing for a graceful exit procedure.

When this configuration is set and prior to exiting the container, the container is removed from the service provider list so that it has no external request. Hook can be executed executed prior to stopping.

• Execute hook before stopping:

  • HTTP GET method: Sends graceful stop container HTTP GET request to IP address of the container on a specified port and path.
  • Container command: Performs graceful stop container command within the container.

• Request parameters:

  • Wait time: Wait time for graceful exit. If this time is exceeded, a SIGKILL signal is sent immediately to kill all of the processes within the container, optional, default is 30 seconds.

Best practices

Best practices for graceful stop

We provide a comprehensive guide to the graceful stop configuration of all applications. The entire flow of the graceful stop function from development to online environment is also provided for each service type. Please see Application Graceful Stop Best Practices to learn more.

Access to services such as Database and Redis/Memcached

Deployed in AppEngine(K8s) applications, including backend services and requirements such as access to own KSYun/aws account Database or Redis/Memcached

1. Establishing VPC docking with Eco Cloud
2. Modify security groups for cloud services to allow specific segments to access the Eco Cloud
3. Modify the network policy for the application space to allow access to backend services

Establishing VPC docking with Eco Cloud

If you have not yet established VPC docking with the Eco Cloud (Peering Connection), please initiate a docking request in the KSYun/aws console using the Eco Cloud VPC information in the following table, then contact the Eco Cloud administrator for approval.

After AWS completes docking, the two sides also need to add their own route. Please provide your VPC network section to the Eco Cloud administrator.

KSYun does not require its own routing operation.

Modify security groups for cloud services to allow specific segments to access the Eco Cloud

According to the application's region, add the security group to the backend service based on the network segment provided in the following table.

Modify the network policy for the application space to allow access to backend services

In order to ensure isolation and security, by default applications on the AppEngine are not allowed to access private addresses. Please contact the Eco Cloud management cloud to provide backend network segments in order to configure network policies to allow access to these network services.

AWS backend services, users can ping the service domain name to get the network segment. Generally speaking, VPC network segments can be provided.

The network segments for the KSYun backend service are the network segments for the endpoint subnet, and can also provide all of the VPC network segments.