Rather than being based on a logical VM image like a VM-based service, a container-based service is based on a Docker image. Other differences between VM-based services and container-based services:
- VM-based services have firewall rules, while container-based services have Container port.
- VM-based services have external lifecycle actions, while container-based services have lifecycle hooks.
- Container-based services do not have service parameters.
To add a new container-based service, from the Services page, click the Add Service link in the upper right of the screen. This brings you to the Add a New Service page as shown in the screenshot below. Select Container Service
A Container Service neither has an Agent nor does it have associated Lifecycle Actions.
If you place the container service under the Custom Service category, you cannot select multiple replicas during deployment.
There are three sections of the service definition form that are unique to container services:
The following screenshot shows the Images fields.
Complete the fields in the Images section as described in the following table.
|Image Prefix||Provide the full URL or relative path of the image. If you provide the relative path, the target Kubernetes cloud will use the associated image in the Docker hub.|
|Default Image Version|
Optional. If left blank, the most recent version of the image at the location specified in the Image Prefix field is used.
Workload Manager does not do a pre-deploy check to see if the image version you enter is valid. If you enter an invalid version name, the associated deployment will fail.
|Image Initialization Command||Optional. Overrides the image's entrypoint command with the specified command. The command is entered as an array of strings, each string on its own line, where each string represents the corresponding "fragment" of the entire command string. Split the command string into fragments as you would if you were to specify it as a command array of strings in a Kubernetes pod configuration YAML file. See https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/ for an example.|
|Image Initialization Arguments||Optional. Lets you pass specific arguments to the command specified in the Image Initialization Command field (if one is specified), or to the default entrypoint in the image. Each argument must be on a desperate line.|
In a Container Service, the Container Ports field refers to the exact port and protocol that the container listens on and must be exposed for external access.
The Container Service can expose more than one port. For example, a Web Server container can expose both Port 80 and Port 443.
A screenshot of this section is shown below.
When you add a container port in the service definition, it will use a Kubernetes service type of Cluster IP.
Lifecycle Hooks are actions that you can define for container-based services in a service definition. These scripts are executed inside the container when the application profile tier that has the Container Service is deployed on Kubernetes.
Any script in a HTTP repository that is supported by the new Container Service type
The Container service does not support IPAM and VM naming callout scripts.
The following image shows the lifecycle hooks input fields.
You must first select the type of lifecycle hook from the dropdown: either one of the listed HTTP repositories in the dropdown, URL or Command.
If you select one of the HTTP repositories in the dropdown, the adjacent field to the right is used to enter the path of the command relative to that repository.
If you select URL from the dropdown, the adjacent field to the right is used to enter the URL.
If you select Command from the dropdown, the adjacent data entry area to the right is used to enter an array of strings, each string on its own line, where each string represents each space delimited fragment of the entire command string. Split the command string into fragments as you would if you were to specify it as a command array of strings in a Kubernetes pod configuration YAML file. See https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/ for an example.
Container Tier Properties in an Application Profile
The following table describes the container-specific tier properties. The other tier properties are discussed in Understand Application Tier Properties.
Base Image Version Tag
Image Initialization Command
Image Initialization Arguments
A screenshot of the General Settings properties is shown below
The base imagine version tag, image initialization command, and image initialization arguments are all inherited from the service definition (see Images above) but can be overwritten in the General Settings section. If the base image version tag is left blank, the latest version is assumed. If you specify an image version tag, that tag is carried over to Page 1 of Deploy form in the per tier settings for that tier. In the deploy form you can delete that version tag or overwrite it with another one.
|Volumes||Provide the mount path to the application that will be using this image along with the default size being used for this volume.|
|Deployment Parameters||Add a Parameter|
If deployment parameters have been defined at the service-level, those parameters are inherited and displayed here.
as the default value for the WORDPRESS DB HOST parameter in the Topology Modeler, as shown in the following screenshot.You can also add parameters specific to the deployment. See Using Parameters for additional context on adding deployment-level parameters.
The following screenshot shows the Network Services parameters.
The Container Ports you defined in the service definition are inherited and displayed here. If your tier contains multiple containers in a single pod, the container ports listed will be the union of all container ports for all containers in the pod. You can add additional container ports here by selecting the service type from the dropdown (Cluster IP, Node Port, or Load Balancer), port number, service name, and then click the Add button to add the port to the tier. The additional ports you create here apply to all containers in the pod.
By default, the service name created by Workload Manager and passed to the Kubernetes endpoint to deploy the tier will be the service name entered by the user appended by a hyphen, the job ID, another hyphen, and a 6 character random string. If the Generate Unique ID toggle is switched off in the application profile, at deploy time, the application will be deployed with the service name identical to name specified in the application profile without any characters appended. If the user-specified service name is not unique relative to all other existing service port names in the Kubernetes namespace associated with the Kubernetes account used for the deployment, the deployment will fail.
By default, Workload Manager will append a hyphen, the job ID, another hyphen, and a 6 character random string to the end of each service name before deploying the pod. This ensures that the service name is unique in the namespace. If you feel confident that the service names you assigned in the service definition and application profile will be unique in the namespace where you deploy the containers, you may turn the Generate Unique ID toggle to OFF.
If your user-specified service name is not unique relative to all other existing service port names in the Kubernetes namespace associated with the Kubernetes account used for the deployment, and you turn the Generate Unique ID toggle off in the application profile, the deployment will fail.
|Firewall Rules||Container Port/Protocol|
Firewall Rules define who can access the container.
By default, when you add Container Service to an application profile, a default firewall rule is added for each container port in the service to be accessed from any IP on the Internet.
However, if you enabled Inter-Tier Communication (Firewall Rules) in the Basic Parameters section for an application profile, then the topmost tier has a default firewall rule added for each container port in the service to be accessed from any IP on the internet. See Security and Firewall Rules > Inter-Tier Communication (Firewall Rules) for additional context.
For other dependent tiers, the default firewall rule is added for each container port in the service that is accessed from the dependent tier.
You can choose to keep the pre-configured firewall definition or add/edit any firewall rules as required. All firewall rules are optional in this field.
In the Workload Manager UI, the Column Name changes to Container Port/Protocol if you are deploying a container service.
The following screenshot shows firewall rules.
|Minimum Resource Specification||One thousand MilliCPUs is equal to 1 CPU and Memory is measured in bytes. |
This configuration depends on the container capabilities. See Managing Compute Resources for Containers for additional context.
Cost and Reports
Billing and Reporting are currently not supported for Container Services.
- No labels