You are here: Deployment Automation > Deployment Examples > Examples: Modeling and Deploying Applications

Examples: Modeling and Deploying Applications

You can model applications using one of the following:

You can use Change Tracking to track all the changes for non-runtime objects such as the application model, components, artifacts, resources, the environment model, and projects. Go to Configuring Change Tracking for more information.

When defining a component or container , you specify the artifact repository (plugin) and the artifact version that you want to use. ElectricFlow supports artifacts from a variety of Artifact Repositories, such as the EC-Artifact repository, Maven based repositories such as Nexus or Artifactory (using EC-Maven), or artifacts on any file system (using EC-FileSysRepo). These artifacts could point to any build outputs, configuration scripts, database, scripts, and so on. The information that you enter in the component or container definition depends on the artifact repository that you select. For more information about artifacts, go to Artifact Management and Artifacts.

Applications consist of services and the processes that orchestrate the deployment of these services. Each application object has one or more application services, where a service is a logical group of containers. A container is based on an artifact, and the container definition contains a reference to this artifact.

When using containers and services, you can:

These examples show how to model and deploy an application in ElectricFlow.

Creating a New Application

Applications consist of components and the processes that orchestrate the deployment of these components. Each application object has one or more application tiers, where a tier is a logical group of components, and one or more services, where a service is a logical grouping of containers.

A component is based on an artifact, and the component definition contains a reference to this artifact.

This example shows how to create a “hybrid” application consisting of an application tier with a component and two services with a container in each service.

Authoring Component Processes

In a component process, you define a set of actions that will be executed on a specific component during the deployment. A component process step can be defined as a call to an ElectricFlow plugin or procedure, a direct command or script in any scripting language, a manual task, or a utility function (a higher-order operation than a plugin).

In the Cleanup DB component of the "DB" tier:

  1. Click to start authoring a component process.

    The Component Process dialog box appears:


  2. In the Component Process dialog box, enter the following details:

  3. Click OK.

    The Component Process Visual Editor opens.

    The process model shows a process with Start and Finish steps with a New Step in between them.

    Note: Clicking i under the step name displays the details about the process step.

    Example:

  4. Click + in the first step.
  5. Define the first step in the Component Process Step dialog box:

    1. Enter "getScript" in the Name field.
    2. Enter "Retrieve the new sql file" in the Description field.
    3. Use the Continue Running setting in the On Error field. Go here for more information.
    4. Use the all setting in the Run if field. Go here for more information.
    5. Click Next.

    Example:

  6. Define the first step in the Component Process Step dialog box based on a component operation, select Component Operations as the Step Type. The parameters for this process step are automatically inherited from the "update.sql" component.

    Example:

  7. Click OK.
  8. Click + on the bottom of the first step to add a new step below it.
  9. Click + in the second step.
  10. Define the second step in the Component Process Step dialog box:

    1. Enter "apply" in the Name field.
    2. Use the Stop Running setting in the On Error field. Go here for more information.
    3. Use the all setting in the Run if field. Go here for more information.
    4. Click Next.

  11. Define the second step in the Component Process Step dialog box based on a component operation by selecting Procedure as the Step Type. The parameters for this process step are automatically inherited from the "update.sql" component.

  12. Click OK.

This is the component process:

  1. Define an application service and the containers in it.

    A new service named Service1 appears.

    In Service 1, click and select Details to edit the details in the Container Definition dialog box.

    1. Rename the application service to "store-front-end" and click OK.
    2. To define the container: 

      1. Click + under the Container.
      2. Click Create new container.
      3. Enter Config as the container name, and click Next. The Container Definition dialog box appears:

      4. Click the "down" arrows to fully expand the dialog box.
      5. Enter the container attributes as needed. The following table describes the available attributes.

        Label Description Default
        Container Definition
        Registry Type

        Public: Specifies that your container images are stored in a public Docker registry.

        Private: Specifies that your container images are stored in registries other than a public Docker registry.

        Public
        Registry URL (Optional) Private container registry URL. This is the registry where your image is stored. For example, http://gcr.io.
        Registry Credential

        (Optional) Credentials (username and password) required to access the private registry. You must create a credential under a project and attach to it ( by providing the absolute path when using ectool or by browsing and selecting it in the UI).

        Image Relative or absolute path to the container image. For example, username/image.
        Version (Optional) Version of the image. For example, v1.0. This will be used as a tag when you publish an image to Docker Hub. If a tag is not provided, Docker tags it as latest. latest
        Volume Mounts

        (Optional) Volume mounts required by the container. Use JSON format. For example:

        [{

        "name": "scratch-space", // required attribute. To be used to reference volume definition at service level.

        "mountPath": "/tmp/cache" // required attribute. Mount location for volume in container.

        }]

        Minimum CPU Requested

        (Optional) Amount of CPU (in number of cores) requested by the container. Specifying the amount of CPU needed allows the underlying container service to make better placement decisions when deploying the services on the nodes in the cluster based on the available capacity.

        If no value is specified, the underlying container service determines the default.

        Maximum CPU Allowed (Optional) Maximum amount of CPU (in number of cores) that the container may use. If the limit is exceeded, the behavior depends on the container service. If this is left empty, the platform-specific default is used.
        Minimum Memory Requested

        (Optional) Amount of memory (in MB) requested by the container. Specifying the amount of memory needed by the container allows the underlying container service to make better decisions when deploying the services on the nodes in the cluster based on the nodes' available capacity. If no value is specified, the underlying container service determines the default.

        None. However, on ECS, the plugin will use a default soft memory limit (memory request) of 128 MB.
        Maximum Memory Allowed (Optional) Maximum amount of memory (in MB) that the container may use. If the limit is exceeded, the behavior depends on the container service. If this is left empty, the platform-specific default is used.
        Entry Point

        (Optional) Comma-separated list of one or more values to override the ENTRYPOINT instruction in the Docker image at runtime. ENTRYPOINT specifies a command that will always be executed when the container starts. For example, /bin/ping.

        For details about how CMD and ENTRYPOINT interact, see https://docs.docker.com/engine/reference/builder/#/understand-how-cmd-and-entrypoint-interact.

        Command (Optional) Comma-separated command arguments to use with the container's entry point. If specified, they override the CMD instruction defined in the container image. CMD specifies arguments that will be passed to the ENTRYPOINT (for example, localhost).
        Environment
        Variable (Optional) Environment variable name used in the container. For example, TEMP_FOLDER or DB_PORT.
        Value (Optional) Default value for the environment variable. You can override these values during the service-to-cluster mapping phase.
        Ports
        Name (Optional) Logical name for the container port. For example, http or https.
        Container Port (Optional) Port that the container is listening on.

         

      6. Click OK.

  2. Click the button to add a service named store-backend as described above and enter the container attributes as needed.

Authoring Application Processes

At the application (parent) level, you author application processes. When deploying an application, the application process that you select is executed to orchestrate operations against the application. An application process step can be defined as a call to an ElectricFlow plugin, procedure, or component process as well as a direct command, script, a manual task, or a utility function (a higher-order operation than a plugin).

In the Applications Visual Editor for the Upgrade application:

  1. Define the second step in the Application Process Step dialog box based on a service by selecting Servicestore-backend. The step is defined by the component Deploy process for the motorbikeMS service.

  2. Click .

This is the application process called "deploy.":

Creating Environments

Environments are logical grouping of machines to which various applications can be mapped and deployed. Using environments and templates, you can model the infrastructure and the middleware available for various applications. Environments consist of logical groups of resources with a similar function or role called environment tiers. An environment tier can be a group of machines with a similar function or role, such all the web servers or application servers or database servers for an environment. Resources are actual target end point machines (such as physical servers), virtual machines, or mobile devices.

Environments can be static, dynamic, or hybrid. A static environment has resources that are already provisioned and managed at the platform level. Each resource has its own logical name to identify it from the other resources in the system. It also can be assigned to one or more resource pools or to a zone (a collection of agents). Several resources can correspond to the same physical host or agent machine. Resources can also be configured as standard or proxy. Standard resources are machines running the ElectricFlow agent on a supported agent platform while proxy resources (agents and targets) are on remote platforms or hosts that exist in your environment and requires SSH keys for authentication. The ElectricFlow agent does not need to run on the remote platform or host. Go to Resources for more information about to create, configure, and manage resources.

This example shows to how model a static environment to which the application will be deployed. For information about dynamic environments and how to model them, go to Deploying Applications in Dynamic Environments.

Creating Environment Tiers

In the Environments List:

  1. Click Add + (in the upper right corner) to add an environment.
  2. The Environment dialog box appears.

  3. Enter 'A—Amazon ECS Production' into the Name field.
  4. Select a project to which the new environment will belong in the field and enter a description of the environment.

    Note: You can include hyperlinks as part of an object description for any ElectricFlow object.

    Example:

    This dialog box lets you quickly define an environment tier and the resources in it or a service and the nodes in it.

  5. Click OK.

    The Environments Visual Editor opens.

  6. Click Tier 1.
  7. Define an environment tier and assign resources it.

    1. In the New dialog box, click Add resources.
    2. Click , then click Details, then rename the environment tier to "mysql," and then click OK.
    3. To define the resource: 

      Click + under the Resource.

      Click Add resources.

      Select the resource that you want to assign to the environment tier, and click . A resource is available if it is enabled.

      Example:

     

    The Environments Visual Editor now has an environment tier called "mysql" with one resource.

    Example:

Creating Environment Clusters

  1. Click + at the bottom of Cluster 1. The Cluster Definition dialog box appears:

  2. In the Cluster Definition dialog box, select a platform. For example, Amazon EC2 Container Service.

  3. Enter the cluster attributes as needed. The following table describes the available attributes.

    Description Default
    Configuration Name of an existing configuration which holds the connection information for Amazon ECS.
    Container Cluster Name Name of the cluster to be provisioned for in Amazon ECS.
    Description (Optional) Description of the cluster that needs to be provisioned.
    Desired Capacity Number of EC2 instances that should be running in the group.
    Maximum Size (Optional) Maximum size of the group.
    Minimum Size (Optional) Minimum size of the group.
    VPC Subnet Ids (Optional) Comma-separated list of subnet identifiers for your virtual private cloud (VPC) in which to launch the EC2 instances.
    Availability Zones Availability zones in which to launch your EC2 instances.
    Image ID of the Amazon Machine Image (AMI) to use to launch your EC2 instances.
    Instance Type Instance type of the EC2 instance.
    Security Groups One or more security groups with which to associate the instances.
    Key Name (Optional) Name of the key pair.
    Associate Public IP (Optional) Checkbox that specifies whether to associate a public IP address.
    Container Instance IAM Role ECS container instance IAM role for the launched container instances to use.
    Results Property Sheet Name of the property sheet to hold results.
  4. Click OK.

  5. In the cluster that you just created, click Details.

    The Environment Cluster dialog box appears:

  6. In the Environment Cluster dialog box, enter a cluster name into the Name field. For example, ecs-cluster1.
  7. Click OK.

Defining Tier Maps and Cluster Maps

Before deploying application that use an application tier or an application cluster, you must define a tier map to associate the application with an environment.

Defining an Application Tier Map

In the Applications Visual Editor for the application that you want to deploy:

  1. Click Environment.
  2. Example: Select Amazon ECS Production.

  3. Map the application tier to the environment tier:

    1. In the application tier, click in the corresponding environment tiers column and select an environment tier. Select one from the list or enter the search criteria in the Search field.

    2. Click OK when the application tier is mapped to an environment tier.

Defining an Application Cluster Map

You can override the service and container attributes and add platform-specific service and container attributes.

  1. Map the store-backend to an environment tier:

    1. In the service, click in the corresponding environment tiers column and select an environment tier. Select one from the list or enter the search criteria in the field.

      Example:

    2. Click OK when the application tier is mapped to an environment tier.
  2. Map the store-front-end service to an environment tier as described above.

    The application now has one tier map and two cluster maps.

    Example:

  3. Click to configure the cluster map for the store-backend service.

  4. Enter the cluster map attributes as needed. The following table describes the available attributes.

      Label Description Default

    Service Configuration Details

    You can use these fields to override the service and container attributes and add platform-specific service and container attributes.

      Volume

    (Optional) Volume pointing to a storage device or a partition that can be mounted by a container. Use JSON format. For example:

    [{

    ""name"": ""web-content"",

    ""hostPath"": ""/var/html"" Location on host/container instance where volume is expected to be already attached.

    }]

    Number of Service instances (Optional) Number of service instances to use. 1
    Rolling Deployment—Min Service Instances (Optional) Minimum number of services that can be brought down during a rolling deployment. If this is left empty, the platform-specific default is used.
    Rolling Deployment—Max Service Instances (Optional) Maximum number of services that can be created during a rolling deployment. If this is left empty, the platform-specific default is used.
    Port Mapping
      Name Reference to the container port name.
    Container Port Reference to the container port.
    Listener Port External or listener port mapping for the container port. A listener port setup is required for pods to communicate with each other.
    Amazon EC2 Container Service Specifications
      LoadBalancer Name Name of the load balancer on Amazon EC2. Required if the service contains port mappings.
    IAM role for Service and Loadbalancer Name or full Amazon Resource Name (ARN) of the AWS Identity and Access Management (IAM) role that allows ECS to make calls to your load balancer on your behalf.
  5. Click to configure the cluster map for the store-front-end service as described above.

Deploying and Troubleshooting Applications

This example shows how to deploy the application multiple times with different runtime conditions.

First Run

In the Applications List, clicking and selecting New Run opens the dialog box where you can set the runtime settings.

Click OK to start the application run.

The Applications View Run page shows the progress of the application run:

Subsequent Runs

After the first application run, you can deploy the Run process to the QA environment with other deployment options.

Based on the Last Run

Clicking and selecting Last Run opens the dialog box where you can set the runtime settings. It displays the runtime settings from the previous. You can deploy the application using the same settings as the previous run or you can modify one or more them for the current run.

Based on Schedules

 

Clicking and selecting Schedule opens the list of schedules for the application. If there are no schedules, the list looks like this:

Clicking There are no Run Schedules. Add one (or Add +) opens the Run Schedule dialog box.

In the Run Schedule Details dialog box, enter the schedule details:

When you view the list of schedules for the application again, the schedule that you created appears in the list.

Runtime Settings

 

In the dialog box where you can set the runtime settings, the Artifacts field looks like this for a full run:

Viewing the Real-Time Progress of Deployments

This example shows the job details for a specific step. Clicking in the "cleanup db" step opens the Job Details page:

 

This example shows that the rollback step has not run yet:

Clicking in the rollback step opens the Job Details page, showing that the status is Waiting for Precondition. This step will not run until the precondition is met.

Troubleshooting Deployments

This example shows that the "start server" step was Completed with Errors.

Clicking in the "start server" step opens the Job Details page.

Clicking in the Diagnostics tab can provide more information about the errors.

of