IBM Technical Exchange Automation User Group India

IBM Technical Exchange Automation User Group India

The IBM TechXchange Automation User Group India is formed to bring together practitioners of IBM Automation technologies in India. The User Group is created with the objectives as given below.

 View Only

Deploying Microservices on IBM Code Engine

By Harisha Paildar posted yesterday

  
Co-Authored by : Mahesh Gupta

What is IBM Code Engine?

IBM Code Engine is a fully managed, serverless platform that allows developers to run containerized workloads, including microservices, batch jobs, and event-driven functions—without worrying about infrastructure.


Prerequisites

Before you begin, make sure the following are in place:

  • 🔐 IBM Cloud Account: Ensure you have an active IBM Cloud account.

  • 📦 Container Registry Access: Your account must have access to IBM Cloud Container Registry or any supported registry.

  • 🐳 Dockerfile: A Dockerfile should be ready to build your microservice image.

  • 🔑 SSH Key: Ensure your SSH key is set up for secure access and operations, if required.

  • 🔐 Registry Secret: A registry secret must be created and available to allow Code Engine to pull your container image.


Log in to IBM Cloud → Navigate to Containers → Select 'Serverless Projects' → Click on 'Create Project



Head over to your project dashboard, and follow these steps:

    1. Navigate to the “Applications” section from the left-hand menu.

    2. Click on “Create Application” to begin configuring your microservice deployment.

You’ll be prompted to configure your application:

    • 📝 Application Name: Start by entering a unique and descriptive name for your application. This will be used to identify it within your project.

    • 🔧 Build Option: Select "Build a container image from source code." This tells IBM Code Engine to automatically build your container image based on the code in your Git repository, rather than using a pre-built image.



Click on “Specify build details” to open the configuration panel.

Here’s what you need to do:

    • 🔗 Repository URL: Enter the SSH Git repository URL where your application code is hosted. This allows Code Engine to securely pull your source code.

    • 🔐 SSH Secret: Select an existing SSH key from the dropdown. If you haven’t added one yet, you can easily create a new SSH secret within the interface. This secret authorizes Code Engine to access your private repository.

    • 🌿 Branch Name: Specify the branch you want Code Engine to use for the build—typically main or dev, depending on your workflow.



Here, you’ll need to provide the following details:

    • 🔄 Build Strategy: Choose the appropriate build strategy (e.g., Dockerfile or Buildpacks) depending on how your application should be built.

    • 🐳 Dockerfile Path: If you're using the Dockerfile strategy, specify the relative path to your Dockerfile within the repository. For most cases, this will be Dockerfile at the root, but adjust it based on your repo structure.

    • ⏱️ Build Timeout: Set the maximum amount of time the build should take before it times out. This helps avoid stuck or overly long builds.

    • 💻 Build Resources: Select the compute resources (CPU & memory) to be allocated during the build process based on the complexity and size of your build.


After setting the build strategy and resource configurations, click “Next” to proceed to the final step of your application setup.

In this section:

  • 🔑 Registry Secret: Select an existing registry secret that grants access to your container registry. If one isn’t available, you can easily create a new secret directly within the interface to enable secure image push/pull operations.

  • 📦 Image Repository: Specify the destination image repository where the built container image should be stored. This could be IBM Cloud Container Registry or any compatible container registry you have access to.

Once all the details are in place, click on “Done” to complete the setup.



Once your application configuration is complete, scroll down to the “Resources and Scaling” section to fine-tune how your application performs under varying workloads.

Under this section, you can customize:

  • ⚙️ CPU & Memory: Define how much compute power your application instance should consume. Choose values based on your app’s resource needs—balancing performance and cost.

  • 💾 Ephemeral Storage: Specify the amount of temporary storage your application may need during runtime.

  • 📈 Auto-Scaling Options: Enable scaling policies to automatically adjust the number of running instances based on traffic. This ensures optimal performance and cost-efficiency. You can set:

    • Minimum instances to keep always-on availability.

    • Maximum instances to limit scaling for cost control.



As you scroll further down the configuration page, you’ll find the “Environment Variables” section.

If your microservice relies on any environment-specific values—such as API keys, database URLs, or configuration flags—you should define them here.

    • 🧩 Click on “Environment Variables”.

    • ➕ Add each variable by specifying the key and its corresponding value.



Continue scrolling down until you reach the “Image Start Options” section.

Here, you’ll need to specify the listening port your application uses to accept incoming requests.

  • 🎯 In the Listening Port field, enter the same port number you’ve exposed in your Dockerfile using the EXPOSE instruction (e.g., 8080).




To ensure your application is only routed traffic when it’s ready to serve, you can define a Readiness Probe.


Scroll down to the “Readiness Probe” section and follow these steps:

    1. Click on "Readiness Probe" – a configuration panel will appear on the left-hand side.

    2. From the Protocol options, select HTTP.

    3. 🔌 In the Port field, enter the listening port you’ve defined earlier (the same one used in your Dockerfile and Image Start Options).

    4. 🛣️ In the Path field, provide the HTTP endpoint that returns a 200 OK response when the application is ready (e.g., /, /health, or another default GET route).


Once all configurations are complete—source, build strategy, environment variables, scaling, and readiness probe—you're ready to launch your microservice.

Scroll to the bottom of the page and click the “Create” button.

📦 Behind the scenes, IBM Code Engine will:

  • Clone your repository

  • Build the container image using the specified Dockerfile or strategy

  • Push the image to the configured container registry

  • Deploy the containerized microservice

  • Expose it via a public URL


Once the build process completes successfully, your code is deployed, and an instance of your microservice is created within IBM Code Engine.

  1. To verify that everything is working as expected:

    1. Navigate to your newly created application.

    2. Click on “Test Application.”

    3. Send a request to the provided URL.


To retrieve the public-facing URL of your deployed microservice:

  1. Navigate to the “Domain Mapping” section within your application settings.

  2. Here, you’ll find the automatically generated public host URL assigned to your application.

🔗 This host URL is what you'll use to interact with your microservice from other applications, frontend clients, or external systems.


Now that you’ve obtained the public host URL from the Domain Mapping section, it’s time to test if your microservice is running correctly.


In this example, let’s verify the health endpoint:


curl https://<your-host-url>/health

📥 This endpoint is designed to respond with the application’s status.

✅ If everything is working as expected, you should receive a response like:


{ "status": "UP" }

This confirms that:

  • Your code has been successfully built and deployed

  • The application instance is active

  • The endpoint is live and responsive





0 comments
24 views

Permalink