Managing Deployment on a Docker Container

When configuring the deployment details in a deployment stage, if you select the Docker deployment mode, the Docker Container section is active on the Deployment tab within that stage. The cloud accounts that you select during stage configuration are listed in the Docker Container section.

To manage your deployments in your desired Kubernetes cluster from this section, do the following:

Configure a Cloud Instance

1. On the Deployment tab, in the Docker Container section, all the cloud accounts configured for your deployment stage are displayed.

   Each cloud account card represents a configured cloud account. From each card, you can add instances to deploy your technologies to that specific account.

   Click +Add Instance and choose a machine configuration option that suits your deployment requirements.

   

   One or more of the following options are available depending on the platform configuration enabled by your administrator.

   • Large - 8GB RAM 2vCPU

   • Medium- 4GB RAM 2vCPU

   • Small- 2GB RAM 2vCPU

   • Custom configuration

   Select the appropriate configuration option for your cloud server instance.

   

   

   Note:

   If your desired instance configuration option is not available in the list, contact your platform administrator.

2. Click Configure to define the cloud account and network settings.

   

3. In the Cloud Account and Network Settings side drawer, your chosen instance type, memory, and CPU configuration are displayed at the top. Review the instance configuration and then do the following:

   Field	Action/Description
   Name	Provide a logical name for your instance.
   Hard Disk Size	Select the desired hard disk size from the list. The disk size determines how much space is available for your container images, logs, and application data. For Docker deployments, 20 GB is the recommended minimum size. Increase the size if your applications handle large data volumes or generate heavy logs.
   Cloud Account	The cloud account on which you configure a cloud instance is auto-populated.
   Use Public or Private Subnet	Enable the Use Public Subnet toggle to launch the instance in a public subnet. Then, select a Public Subnet from the dropdown. Otherwise, select a Private Subnet from the dropdown to deploy the instance within a private network.
   Security Groups	Select one or more security groups. They act as virtual firewalls controlling inbound and outbound traffic for instances hosting your Docker containers.
   Application Security Groups (Optional)	If you configure settings for an Azure instance, select one or more application security groups. This field is optional.
   AMI ID (Optional)	Select the unique ID of the Amazon Machine Image (AMI) that you want to launch.

4. Click Save to create the instance and apply the specified cloud and network settings.

   

Creating Load Balancer Manually

If, while creating or editing a stage, you choose to manually create a load balancer for your Docker deployment, you must configure the load balancer to complete your technology deployment.

Click Configure Load Balancer.

In the Configure Load Balancer side drawer, complete the steps mentioned on the UI, get the DNS name of your load balancer, and provide it in the DNS Name field.

View Technologies Pending for Deployment

In the Docker Container section, in the upper left corner, the list of ready-to-deploy technologies that you have added in the Develop phase is displayed. You can search for your desired technology in the list by the technology name or its title that you give while adding it in the Develop phase.

Add Technologies for Deployment

After you define the cloud account and network settings for your cloud server instance, you can add and configure the technologies you want to deploy within the Docker containers on the configured cloud instance. Do the following:

1. Click Add Technologies. The list of ready-to-deploy technologies that you have added in the Develop phase is displayed. You can search for your desired technology by the technology name or its title that you give while adding it in the Develop phase.

2. To add a technology for deployment, click Add next to the desired technology .

   
   

3. In the side drawer, configure the following details required for the deployment. These settings ensure your application is packaged, built, and deployed correctly within the selected cloud account.

   Depending on the CI/CD tool selected in your deployment stage configuration, some configuration options and the overall flow will vary. The following sections describe the configuration process separately for Jenkins and GitHub Actions.

   If Jenkins Is Your CI/CD Tool

   1. Specify Context Path

   In the Context Path field, specify the context path for your application. The context path defines the URL segment through which users can access your containerized application once deployed.

   For example, if you set the context path to "/banking-service", users will access your application at "https://yourdomain.com/banking-service".

   Use a short, meaningful path name that reflects the application or service being deployed.

   2. Configure Continuous Integration (CI) Settings

   Continuous Integration automates the process of building, testing, and preparing your application whenever code changes occur or based on a defined schedule.

   • Source Code Branch

     Select the specific branch from your source code repository that contains the code you want to deploy. Your CI pipeline will monitor this branch for changes.

   • Trigger Types

     The CI trigger determines when the pipeline should start:

     • Code Change – The pipeline runs automatically whenever changes are committed to the selected branch. Ideal for active development workflows.

     • Manual – The pipeline is triggered only when you explicitly start it from the platform. Suitable for controlled build scenarios.

     • Schedule – You can define one or more time-based schedules to run the CI pipeline automatically at specific times. Useful for periodic deployments and testing.

       In each schedule, you can specify the following:

       1. Time Zone: Select the desired time zone for the CI trigger schedule.

       2. Frequency : Select the Every Day or Every Week option as required.

       3. Time: Define when to trigger the pipeline (in hours and minutes). You can define multiple schedules as well.

       Best Practice:

       • Use Code Change in development to get instant feedback on commits.

       • Use Manual in production to avoid unintentional deployments.

       • Use Schedule for batch updates or automated maintenance windows.

   3. Configure Continuous Deployment (CD) Settings

   Continuous Deployment defines how and when your built image is deployed as a running container.

   • Port Number

     Enter the port number on which your application will be exposed. It is important to ensure that the specified port is open and available for successful communication.

   • Trigger Types

     The CD pipeline trigger determines when the container deployment starts after the build completes.

     • Run after Continuous Integration – Automatically deploys the container immediately after a successful CI run. Ideal for lower environments like Dev or QA to enable continuous delivery.

     • Manual – Deploys only when triggered manually from Calibo Accelerate. Recommended for production or controlled release environments.

     • Schedule – You can define one or more time-based schedules to run the CD pipeline automatically at specific times. Useful for periodic deployments and testing.

       In each schedule, you can specify the following:

       1. Time Zone: Select the desired time zone for the CD trigger schedule.

       2. Frequency : Select the Every Day or Every Week option as required.

       3. Time: Define when to trigger the pipeline (in hours and minutes). You can define multiple schedules as well.

   

   Note:

   The Run after Continuous Integration and Schedule triggers become active only after the technology has been deployed manually at least once from Calibo Accelerate.

   This ensures that the required Docker infrastructure, network settings, and instance configurations are properly initialized before automated deployments begin.

   

   4. Functional Testing (Optional)

   Enable Functional Testing if you want to perform end-to-end automation testing after the container is deployed.

   1. Testing Tool: Choose your preferred functional testing tool from the list. Currently, the Calibo Accelerate platform supports the following testing tools:

      • Selenium

      • Cypress

   2. Browser: This field is available if you select Cypress as a testing tool. Select the web browser in which you want to run your Cypress tests.

   3. Test Case Repository: Specify the URL of the repository where your test cases are stored. For example, https://github.com/your-username/your-cypress-repo.git

   4. Test Case Repository Branch: Select the branch within the test case repository where your desired test cases are located.

   5. Test Case Command: Enter the command to execute the test suite.

   If GitHub Actions Is Your CI/CD Tool

   1. Specify Context Path

   In the Context Path field, specify the context path for your application. The context path defines the URL segment through which users can access your containerized application once deployed.

   For example, if you set the context path to "/banking-service", users will access your application at "https://yourdomain.com/banking-service".

   Use a short, meaningful path name that reflects the application or service being deployed.

   2. Add Runner Labels

   • What are runners in GitHub Actions?
     In GitHub Actions, a runner is a server that executes the jobs defined in your workflow. Each runner listens for available jobs, runs them when triggered, and reports the results back to GitHub. There are two main types of runners:
     

     • GitHub-hosted runners – Managed by GitHub, automatically updated, and preconfigured with popular tools and languages.

     • Self-hosted runners – Managed by you, allowing custom hardware, software, and network configurations.

   • What are runner labels?

     Runner labels are tags or identifiers assigned to self-hosted runners to categorize them based on their characteristics, capabilities, or intended use. When you specify runner labels in your deployment configuration, the job will be assigned only to runners that match all the specified labels.

   • Specify all intended runner labels

     Specify one or more runner labels to ensure that the GitHub Actions workflow is assigned to an appropriate runner.

     The workflow job is assigned to a runner whose label set matches all specified labels. If no matching runner is available, the job remains in a pending state until one becomes available.

   

   Tip:

   Maintain a documented list of available runner labels in your project so developers know which labels to use.

   3. Configure Continuous Integration (CI) Settings

   Continuous Integration automates the process of building, testing, and preparing your application whenever code changes occur or based on a defined schedule.

   • Source Code Branch

     Select the specific branch from your source code repository that contains the code you want to deploy. Your CI pipeline will monitor this branch for changes.

   • Trigger Types

     You can define one or more Continuous Integration (CI) triggers to automate when your pipeline should run. By default, the Manual trigger is always present and cannot be deleted. You can add additional triggers — After Push and/or Cron Schedule — based on how you want to automate the CI workflow.

     • Default Manual Trigger – The pipeline is triggered when you explicitly start it from the platform. This trigger is preselected and you cannot delete it. This ensures there is always at least one valid trigger method for the pipeline. Suitable for controlled build scenarios.

     • Adding a New Trigger

       Click + New Trigger to define when and how your CI pipeline should be initiated automatically. From the list of available trigger types, select your desired trigger type.

       • After Push – The pipeline runs automatically whenever changes are committed to the selected source code branch. Ideal for active development cycles where continuous integration must occur after every update.

         To add this trigger, select After Push for the list of available triggers, and then click Add.

       • Schedule – You can define one or more time-based schedules (cron expression) to run the CI pipeline automatically at specific times. Useful for nightly builds, periodic testing, or maintenance runs.

         In each schedule, you can specify the following:

         1. Time Zone: Select the desired time zone for the CI trigger schedule.

         2. Frequency : Select the Every Day or Every Week option as required.

         3. Time: Define when to trigger the pipeline (in hours and minutes).

            Click Add.

            You can define multiple schedules as well. To add another schedule, in the Cron Schedule section, click +Schedule and to define the schedule, repeat the steps mentioned earlier.

         Best Practice:

         • Use Manual in production to avoid unintentional deployments.

         • Use Code Change in development to get instant feedback on commits.

         • Use Schedule for batch updates or automated maintenance windows.

         

   4. Configure Continuous Deployment (CD) Settings

   Continuous Deployment defines how and when your built image is deployed as a running container.

   • Port Number

     Enter the port number on which your application will be exposed. It is important to ensure that the specified port is open and available for successful communication.

   • Trigger Types

     After configuring the Continuous Integration (CI) section for a technology deployed on a Docker container, you can define one or more Continuous Deployment (CD) triggers to control when deployment should occur. By default, the Manual trigger is always present and cannot be deleted, ensuring that deployment can always be executed manually if automated triggers are not configured.

     • Default Manual Trigger – Deployment happens only when triggered manually from Calibo Accelerate. This trigger is preselected and you cannot delete it. Recommended for production or controlled release environments.

     • Adding a New Trigger

       Click + New Trigger to define when and how your CD pipeline should be initiated automatically. From the list of available trigger types, select your desired trigger type.

       • After CI – Automatically deploys the container immediately after the associated CI pipeline completes successfully. Ideal for continuous delivery workflows where deployment should immediately follow a successful build and test phase.

       • Cron Schedule – You can define one or more time-based schedules to run the CD pipeline automatically at specific times. Commonly used for scheduled releases, periodic environment refreshes, or maintenance deployments.

         In each schedule, you can specify the following:

         1. Time Zone: Select the desired time zone for the CD trigger schedule.

         2. Frequency : Select the Every Day or Every Week option as required.

         3. Time: Define when to trigger the pipeline (in hours and minutes). You can define multiple schedules as well.

         Click Add.

         You can define multiple schedules as well. To add another schedule, in the Cron Schedule section, click +Schedule and to define the schedule, repeat the steps mentioned earlier.

       

   5. Functional Testing (Optional)

   Enable Functional Testing if you want to perform end-to-end automation testing after the container is deployed.

   1. Testing Tool: Choose your preferred functional testing tool from the list. Currently, the Calibo Accelerate platform supports the following testing tools:

      • Selenium

      • Cypress

   2. Browser: This field is available if you select Cypress as a testing tool. Select the web browser in which you want to run your Cypress tests.

   3. Test Case Repository: Specify the URL of the repository where your test cases are stored. For example, https://github.com/your-username/your-cypress-repo.git

   4. Test Case Repository Branch: Select the branch within the test case repository where your desired test cases are located.

   5. Test Case Command: Enter the command to execute the test suite.

4. Click Add to save the details.

   The technology is added for deployment to your configured cloud instance.

   At this point, you can edit the deployment configuration details for your technology.

   

   In the upper right corner, click Deploy. The list of all your configured and ready-to-deploy technologies is displayed in a side drawer. Select the desired ones, and then click Deploy.
   The time to deploy each technology may vary depending on the technology complexity, size of the application, dependencies, and many other factors related to the deployment environment and network conditions.

5. In the upper right corner, click Refresh to view the latest status of your technology deployments.

   To fetch the real-time status of your technology deployments from the Jenkins server, click Force Refresh.

6. As soon as you initiate technology deployment, an instance is created in your cloud account based on your specified configuration. On the Docker Container tab, the instance tile is the visual representation of that cloud instance. In the upper right corner of the instance tile, you can do the following:

• Monitor the status of your cloud instance.

• Add more technologies for deployment

• Click the ellipsis (...) to do the following:

  • Stop a running instance

  • Remove instance from the cloud account
    

    

    Note:

    To delete an instance from your cloud account, first you must uninstall all the technologies deployed on the cloud instance.

    
    

  • View or edit instance configuration

Deploy Technologies to Docker Container

Depending on the CI/CD tool selected in your deployment stage configuration, some steps in the technology deployment flow vary. The following sections describe the steps separately for Jenkins and GitHub Actions.

Uninstall a Technology

When a technology is no longer required in your product or pipeline, you can uninstall it from Calibo Accelerate. Uninstalling a technology removes its configuration and also deletes the associated Continuous Integration (CI) and Continuous Deployment (CD) jobs from the configured CI/CD tool.

This ensures your product remains clean and that no unnecessary jobs are executed in the background.

To uninstall a technology, do the following:

1. On the technology card, click the ellipsis (...) menu in the upper-right corner.

2. From the dropdown menu, select Uninstall.

   

3. A confirmation dialog box appears.

   • Click Uninstall to proceed.

     

   • Click Cancel if you want to retain the technology.

4. Once confirmed:

   • The selected technology is uninstalled from Calibo Accelerate.

   • Related CI and CD jobs are deleted automatically from the connected CI/CD tool.

Edit Technology Details

After a technology is added to your product, you may need to update its deployment configurations over time. For example, you might want to adjust the context path, update CI/CD settings, or modify functional testing parameters.

To edit technology details, do the following:

1. On the technology card, click the ellipsis (...) menu in the upper-right corner.

2. From the dropdown menu, select Edit Details.

   

   This opens the deployment configuration details for the selected technology.

3. Modify the desired settings.

4. Save your changes.

   With the updated configuration in place, you can now trigger the CI pipeline and deploy the technology to the selected environment.

Recommended Topics

What's next? Data Pipeline Studio