diff --git a/README.md b/README.md index 74033fe13..693c9c367 100644 --- a/README.md +++ b/README.md @@ -2,37 +2,20 @@ # Tutorials and Samples for IBM Cloud Code Engine -This repository is split into two types of educational material: Tutorials -and Samples. - -Tutorials are meant to be complete end-to-end scenarios designed -to teach you about [Code Engine](https://ibm.com/cloud/code-engine) as if you -have limited knowledge of Cloud Native technologies. Each provides a -step-by-step guide walking you through the process of deploying a certain -type of workload - explaining, in detail, each step in the process. The goal -is to not simply have you copy-n-paste each command but rather to understand -the "whys" of what's going on so you can apply what you've learned to one -of your own projects. - -Samples are meant to be "quick-start" tasks that help developers -perform one very specific task. They do not include extra verbose help text -or explanations, rather they are designed for people who have a basic -understanding of Cloud Native technologies and want a quick reminder of how -to perform a certain task in the Code Engine environment. Most samples will -be relatively small so that it can be re-used easily and integrated into a -larger use-case. +This repository contains code samples and scripts for +[IBM Cloud Code Engine](https://ibm.com/cloud/code-engine). Many of them are +accompanied by blog posts and in-depth walkthroughs published in the +[Engine Room](https://ibm.github.io/CodeEngine/) — the go-to resource for +tutorials, how-tos, and best practices built around this content. ### Getting Started Code Engine requires that you use an IBM Cloud "paid account", even if you -don't plan on going beyond the -[free tier](https://www.ibm.com/cloud/code-engine/pricing). +don't plan on going beyond the [free tier](https://www.ibm.com/cloud/code-engine/pricing). #### Cloud Shell -The easiest way to run these are via the -[IBM Cloud Shell](https://cloud.ibm.com/shell) service. This is a browser based -command line that will have all of the IBM Cloud CLI components pre-installed +The easiest way to run these are via the [IBM Cloud Shell](https://cloud.ibm.com/shell) service. This is a browser based command line that will have all of the IBM Cloud CLI components pre-installed for you. To ensure you have the latest versions of each CLI plugin, run: @@ -46,18 +29,14 @@ once you're in the shell. If you choose to use your own machine, then the following need to be installed: - [IBM Cloud command line (`ibmcloud`)](https://cloud.ibm.com/docs/cli/reference/ibmcloud?topic=cloud-cli-getting-started) - [Code Engine plugin (`ce`)](https://cloud.ibm.com/codeengine/cli) -- [Cloud Object Storage plugin (`cos`)](https://cloud.ibm.com/docs/cloud-object-storage-cli-plugin) -- [Event Streams plugin (`es`)](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-cli#step5_es_cli) - for samples which use IBM Event Streams (Kafka) -- [`docker`](https://docker.io/) if you choose to build the images yourself. - For novices, skip this. +- [`podman`](https://podman.io/) or [`docker`](https://docker.io/) if you choose to build the images yourself. For novices, skip this. #### Let's go! Once you have your environment ready, look at the README for the Tutorial or Sample of interest to know if you'll need to clone this git repository first. Most of the Samples will require it since it involves executing their -`run` script. The tutorials will try to avoid this requirement. +`run` script. If you need, or want, to clone this repo simple execute: ``` @@ -65,13 +44,13 @@ $ git clone https://github.com/IBM/CodeEngine ``` and then `cd` into the `CodeEngine` directory. -If you have not already specified your IBM Cloud resource group, then -see the: +If you have not yet targeted a resource group, use the following commands +to list available groups and set the target. The group is often named +`default` or `Default`. ``` $ ibmcloud resource groups $ ibmcloud target --help ``` -commands for more information. Often it is called `default` or `Default`. Most of the material in here assumes you aleady have a Code Engine [project](https://cloud.ibm.com/docs/codeengine#term-summary) already created. @@ -87,12 +66,12 @@ to get started. ## AI Skill for Agentic IDEs Deploy and manage Code Engine workloads directly from your AI-powered IDE like -[IBM Bob](https://bob.ibm.com/) using the **Code Engine Specialist** skill defined in [`SKILL.md`](skills/code-engine-specialist/SKILL.md). +[IBM Bob](https://bob.ibm.com/) using the **Code Engine Specialist** skill defined in [`SKILL.md`](ai/skills/code-engine-specialist/SKILL.md). ### Install via [skills.sh](https://www.skills.sh/) ``` -npx skills add IBM/CodeEngine/skills +npx skills add IBM/CodeEngine/ai/skills ``` ### Example prompts @@ -124,9 +103,6 @@ Deploy this application to IBM Cloud. - [Batch inferencing](serverless-fleets/tutorials/inferencing)
This tutorial provides a comprehensive guide on using Serverless GPUs to perform batch inferencing which illustrates a generally applicable pattern where AI helps to extract information out of a set of unstructed data. -- [Metrics Collector](metrics-collector)
- Re-usable asset that helps to gain insights on the CPU and memory consumption of apps, jobs and builds. - - [Fotobox](fotobox) Deploy your own Fotobox straight to the IBM Cloud access it directly from any device with browser and camera. Take pictures and view them all from your device. diff --git a/assets/code-engine-logo.png b/assets/code-engine-logo.png deleted file mode 100644 index 5de7070fb..000000000 Binary files a/assets/code-engine-logo.png and /dev/null differ diff --git a/assets/code-engine-logo.svg b/assets/code-engine-logo.svg deleted file mode 100644 index ec1a95ee7..000000000 --- a/assets/code-engine-logo.svg +++ /dev/null @@ -1 +0,0 @@ - diff --git a/assets/favicon.png b/assets/favicon.png deleted file mode 100644 index 5de7070fb..000000000 Binary files a/assets/favicon.png and /dev/null differ diff --git a/assets/jeremiaswerner.jpg b/assets/jeremiaswerner.jpg deleted file mode 100755 index fc036c15d..000000000 Binary files a/assets/jeremiaswerner.jpg and /dev/null differ diff --git a/assets/joachimjordan.jpg b/assets/joachimjordan.jpg deleted file mode 100644 index 57f3c53a6..000000000 Binary files a/assets/joachimjordan.jpg and /dev/null differ diff --git a/assets/lukeroy.jpg b/assets/lukeroy.jpg deleted file mode 100644 index 0a93fb89d..000000000 Binary files a/assets/lukeroy.jpg and /dev/null differ diff --git a/assets/saschaschwarze.jpg b/assets/saschaschwarze.jpg deleted file mode 100644 index ae1e3fb63..000000000 Binary files a/assets/saschaschwarze.jpg and /dev/null differ diff --git a/assets/uwefassnacht.jpg b/assets/uwefassnacht.jpg deleted file mode 100644 index ce7364877..000000000 Binary files a/assets/uwefassnacht.jpg and /dev/null differ diff --git a/beta/serverless-fleets/README.md b/beta/serverless-fleets/README.md deleted file mode 100644 index a9dbfba6f..000000000 --- a/beta/serverless-fleets/README.md +++ /dev/null @@ -1,5 +0,0 @@ -# Simplify and optimize large-scale parallel computation with Serverless Fleets - -Serverless Fleets has been GA'd and so the samples and tutorials can be found under a new URL - -https://github.com/IBM/CodeEngine/blob/main/serverless-fleets diff --git a/content/authors/jeremiaswerner/_index.md b/content/authors/jeremiaswerner/_index.md deleted file mode 100644 index 7e8886b17..000000000 --- a/content/authors/jeremiaswerner/_index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: "Jeremias Werner" -text: "Senior Architect (STSM) for IBM Cloud Code Engine" ---- - -Welcome to my blog post feed. diff --git a/content/authors/joachimjordan/_index.md b/content/authors/joachimjordan/_index.md deleted file mode 100644 index cf8d4ce75..000000000 --- a/content/authors/joachimjordan/_index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: "Joachim Jordan" -text: "Tech Lead Code Engine Platform @ IBM Cloud" ---- - -Welcome to my blog post feed. diff --git a/content/authors/josip-ledic/_index.md b/content/authors/josip-ledic/_index.md deleted file mode 100644 index bc538d13f..000000000 --- a/content/authors/josip-ledic/_index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: "Josip Ledic" -text: "Sofware Engineer @ IBM Cloud Code Engine" ---- - -Welcome to my blog post feed. diff --git a/content/authors/lukeroy/_index.md b/content/authors/lukeroy/_index.md deleted file mode 100644 index 8f0ca2c30..000000000 --- a/content/authors/lukeroy/_index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: "Luke Roy" -text: "Cloud Software Engineer @ IBM Cloud Code Engine" ---- - -Welcome to my blog post feed. diff --git a/content/authors/saschaschwarze/_index.md b/content/authors/saschaschwarze/_index.md deleted file mode 100644 index ad6a32ccd..000000000 --- a/content/authors/saschaschwarze/_index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: "Sascha Schwarze" -text: "Senior Software Engineer @ IBM Cloud Code Engine" ---- - -Welcome to my blog post feed. diff --git a/content/authors/uwefassnacht/_index.md b/content/authors/uwefassnacht/_index.md deleted file mode 100644 index 269a7536f..000000000 --- a/content/authors/uwefassnacht/_index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: "Uwe Fassnacht" -text: "Product Manager for IBM Cloud Code Engine" ---- - -Welcome to my blog post feed. diff --git a/content/posts/B300-now-available/featured.jpg b/content/posts/B300-now-available/featured.jpg deleted file mode 100644 index bc102877a..000000000 Binary files a/content/posts/B300-now-available/featured.jpg and /dev/null differ diff --git a/content/posts/B300-now-available/index.md b/content/posts/B300-now-available/index.md deleted file mode 100644 index b221e2e14..000000000 --- a/content/posts/B300-now-available/index.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "NVIDIA B300 GPUs Now Available in IBM Cloud Code Engine Serverless Fleets" -date: 2026-05-26 -description: "B300 GPUs now available in IBM Cloud Code Engine." -tags: ["serverless", "code engine", "GPU", "AI", "serverless fleets", "news"] -featureImage: "featured.jpg" -draft: false -authors: ["uwefassnacht"] ---- - -The AI landscape is moving at a breakneck pace, and today we are shifting into a new gear. We are thrilled to announce that NVIDIA B300 (Blackwell Ultra) GPUs are now also available in IBM Cloud Code Engine Serverless Fleets. - -By bringing NVIDIA’s most powerful Blackwell-architecture GPU to our serverless platform, we are giving developers the ability to run the world’s most demanding reasoning models and massive-scale simulations without the burden of infrastructure management. - -### Why Use B300 with Serverless Fleets? - -- “Serverless Fleets" make the B300 accessible and cost-effective. While Blackwell GPUs are power-hungry (1,400W TDP) and expensive to reserve, Code Engine changes the economics: - -- Zero Idle Costs: The B300 is a high-performance asset. In a traditional setup, you pay for it 24/7. With Code Engine, your Fleet scales to zero when your job is done. Billing starts the moment a GPU is initialized, and you are only charged for the GPU‑seconds it is active. - -- Massive Parallelism without the Headaches: Serverless Fleets allow you to submit thousands of tasks to a single endpoint. Code Engine automatically provisions the B300 resources, distributes the tasks, and decommissions the GPUs when the work is complete. - -- Blackwell-Ready Abstraction: No need to configure liquid cooling or 800Gbps networking. We handle the intense infrastructure requirements of the Blackwell architecture so you can focus on your vllM or PyTorch code. - -- Seamless Model Fitting: The massive 288GB VRAM means you can run larger batch sizes or longer context windows (up to 128k+ tokens) on a single node, significantly reducing the latency overhead of inter-GPU communication. - -### Ready to Scale? - -Whether you are fine-tuning the latest Granite models or running high-throughput inference for a global application, the B300 on Code Engine is your new high-performance home. - -- Get Started: View the [Code Engine Serverless Fleets documentation](https://cloud.ibm.com/docs/codeengine?topic=codeengine-cefleets) to learn how to configure your first GPU-enabled fleet. - -- Step-by-Step Tutorial: Follow our [GPU Batch Processing tutorials on GitHub](https://github.com/IBM/CodeEngine/tree/main/serverless-fleets) for real-world examples. - -- Pricing & Profiles: Visit the [IBM Cloud Pricing Page](https://cloud.ibm.com/containers/serverless/overview) to see the latest rates for B300 GPU-second billing and choose the right worker profile for your workload. - -**The era of Blackwell has arrived. Scale your intelligence, not your operations.** diff --git a/content/posts/Creating-a-ibm-cloud-code-engine-function-code-bundle-FROM-scratch/featured.jpg b/content/posts/Creating-a-ibm-cloud-code-engine-function-code-bundle-FROM-scratch/featured.jpg deleted file mode 100644 index 46f200481..000000000 Binary files a/content/posts/Creating-a-ibm-cloud-code-engine-function-code-bundle-FROM-scratch/featured.jpg and /dev/null differ diff --git a/content/posts/Creating-a-ibm-cloud-code-engine-function-code-bundle-FROM-scratch/index.md b/content/posts/Creating-a-ibm-cloud-code-engine-function-code-bundle-FROM-scratch/index.md deleted file mode 100644 index 1e0b332df..000000000 --- a/content/posts/Creating-a-ibm-cloud-code-engine-function-code-bundle-FROM-scratch/index.md +++ /dev/null @@ -1,108 +0,0 @@ ---- -title: "Creating a IBM Cloud Code Engine Function Code Bundle FROM scratch" -date: 2025-08-04 -description: "Creating a IBM Cloud Code Engine Function Code Bundle FROM scratch" -tags: ["serverless", "code engine", "functions"] -featureImage: "featured.jpg" -draft: false -authors: ["lukeroy"] ---- - -Have you ever wanted to create a Code Engine Function code bundle that runs as a Python or Node.js function on [IBM Cloud Code Engine](https://www.ibm.com/products/code-engine), without relying on the Code Engine CLI to build it? - -This guide walks you through a manual method to create a Code Bundle, giving you more control over the build process. While this approach is not encouraged as it can lead to unexplained behaviours it’s ideal for experienced developers who need flexibility in how their functions are packaged and deployed. - -**Important**: Ensure you run all commands in an **amd64/Linux environment** using the correct runtime version for your function. Refer to the [Code Engine Function Runtimes documentation](https://cloud.ibm.com/docs/codeengine?topic=codeengine-fun-runtime) for supported versions. You should also have a IBM Cloud account and be familiar with IBM Cloud Code Engine and [IBM Cloud Container Registry](https://www.ibm.com/products/container-registry). - -## Step-by-Step Guide -## 1. Prepare your source code - -You can create either a Python or Node.js function for IBM Cloud Code Engine. Example source code for both runtimes is available in the following GitHub repositories: - -- [Python code bundle](https://github.com/IBM/CodeEngine/tree/main/helloworld-samples/function-codebundle-python) -- [Node.JS code bundle](https://github.com/IBM/CodeEngine/tree/main/helloworld-samples/function-codebundle-nodejs) - -Typically, you would use the Code Engine CLI to build and deploy your function in a single step. For example: - -### For Python: -```bash -$ ibmcloud ce fn create -n lorem-python -runtime python-3.11 --build-source . -``` - - -### For Node.JS: -```bash -$ ibmcloud ce fn create -n lorem-node -runtime nodejs-20 --build-source . -``` - -After running one of these commands, your function is automatically built, deployed, and ready to invoke via the generated URL — no additional steps required. -However, in this guide, we’ll manually perform the build and packaging steps. This approach gives you deeper insight and greater control over how your function is constructed and deployed. - -## 2. Installing Dependencies for Your Function - -Once you’ve created your source code files `__main__.py` and `requirements.txt` for Python, or `main.js` and `package.json` for Node.js you can proceed to install any additional dependencies required by your function. Ensure you are in the directory where your source code is. - -### For Python: -Set up a virtual environment and install the dependencies listed in your `requirements.txt` file. This will create a `virtualenv` directory containing all the necessary packages: -```bash -$ virtualenv virtualenv -$ source virtualenv/bin/activate -$ pip install -r requirements.txt -``` -### For Node.js: -Use npm to install the dependencies defined in your `package.json`. This will generate a `node_modules` directory: -```bash -$ npm install -``` -These steps ensure that all runtime dependencies are downloaded and ready for packaging into your Code Engine function. -## 3. Packaging and Publishing Your Function Code and Dependencies - -With your source code and dependencies ready, the next step is to bundle everything into a .tar.gz archive. This archive will later be added to a container image for deployment. - -### For Python: -Include your code `__main__.py`, dependencies `requirements.txt`, and the virtual environment directory `virtualenv`: -```bash -$ tar -czf myfuncbundle.tar.gz __main__.py requirements.txt virtualenv -``` -### For Node.js: -Include your `main.js`, `package.json`, and the `node_modules` directory: -```bash -$ tar -czf myfuncbundle.tar.gz main.js package.json node_modules -``` -Now that your code and dependencies are bundled in a tar.gz , the final step is to create a container image that can be stored in a container registry — specifically, the IBM Cloud Container Registry in this case. -This image will contain a single layer with your function. Note that this is not an executable container, it simply holds the function code for Code Engine to extract and run. - -Create a file named `Dockerfile` with the following content. - -**Dockerfile:** -```dockerfile -FROM scratch -ADD myfuncbundle.tar.gz . -``` -Build the image and push it to IBM Cloud Container Registry using the following commands. Replace mynamespace with your actual IBM Cloud Container Registry namespace: - -```bash -$ docker build -t us.icr.io/mynamespace/myfuncbundle . -$ docker push us.icr.io/mynamespace/myfuncbundle -``` -Once pushed, this image can be referenced when creating/updating your function in Code Engine. - -## 4. Deploying Your Function with a Custom Code Bundle - -With your function code bundle pushed to the IBM Cloud Container Registry, you’re ready to create/update your function using the Code Engine CLI. Instead of building from source, you’ll reference your pre-packaged code bundle stored in the registry. - -### For Python: -```bash -$ ibmcloud ce function create --name myfunc --runtime python-3.11 --code-bundle us.icr.io/mynamespace/myfuncbundle -```` - -### For Node.JS: -```bash -$ ibmcloud ce function create --name myfunc --runtime nodejs-20 --code-bundle us.icr.io/mynamespace/myfuncbundle -``` -Be sure to replace mynamespace with your actual IBM Cloud Container Registry namespace. - -This command creates your function on IBM Cloud Code Engine, using your custom bundle as the source. Once created, the function is ready to be invoked via its generated URL. -## Summary - -By manually creating a Code Engine function bundle, you’ve unlocked a deeper understanding of how IBM Cloud Code Engine handles function packaging and deployment. This method gives you full control over your function dependencies and build, process — ideal for advanced use cases or custom CI/CD pipelines. However, for most scenarios, it is strongly recommended to use the Code Engine CLI, which simplifies the process and ensures compatibility with the platform’s evolving features. While the manual approach is powerful, the CLI remains the most reliable and supported way to build and deploy your functions. Happy coding — and may your functions run fast and fault-free! \ No newline at end of file diff --git a/content/posts/Deploying-apps-jobs-and-functions-using-github-actions/featured.jpg b/content/posts/Deploying-apps-jobs-and-functions-using-github-actions/featured.jpg deleted file mode 100644 index 727461e13..000000000 Binary files a/content/posts/Deploying-apps-jobs-and-functions-using-github-actions/featured.jpg and /dev/null differ diff --git a/content/posts/Deploying-apps-jobs-and-functions-using-github-actions/index.md b/content/posts/Deploying-apps-jobs-and-functions-using-github-actions/index.md deleted file mode 100644 index c44c65838..000000000 --- a/content/posts/Deploying-apps-jobs-and-functions-using-github-actions/index.md +++ /dev/null @@ -1,142 +0,0 @@ ---- -title: "IBM Cloud Code Engine: Deploying Apps, Jobs and Functions using GitHub Actions" -date: 2024-02-23 -description: "Deploying Apps, Jobs and Functions using GitHub Actions" -tags: ["serverless", "code engine", "github actions"] -draft: false -authors: ["lukeroy"] ---- - -## Introduction: -In the dynamic world of cloud computing, efficient deployment pipelines are a crucial part of a seamless development process. IBM [Code Engine](https://www.ibm.com/products/code-engine), a fully managed serverless offering, stands out by simplifying the deployment and running of Applications, Jobs, and Functions in the cloud at scale, eliminating the need for users to manage the underlying infrastructure. - -To elevate the users development experience and workflow, we've introduced a dedicated GitHub Action designed to simplify the deployment process for GitHub users leveraging GitHub Actions as their CI/CD pipeline. - -The GitHub Action `ibm/code-engine-github-action` empowers Code Engine users to seamlessly build and deploy applications, jobs, and functions directly from their GitHub repositories without the need to first manually build the program that they want to deploy or run multiple cli commands. This integration enhances the overall development lifecycle, providing a streamlined and automated approach to deploying and managing Code Engine resources. - -## Getting Started -To get started, ensure that the GitHub Actions feature is enabled for your repository. While GitHub Actions are enabled by default for public repositories, users with private repositories may need to enable it from the Actions tab. All workflow configurations are stored within the `.github/workflows` directory, making it easily accessible for users to customize and manage their deployment pipelines. - -To use the `ibm/code-engine-github-action` GitHub Action you will also need to create an API Key ([see the docs](https://cloud.ibm.com/docs/account?topic=account-userapikey&interface=ui)) and save it as a secret for your repository (Settings -> Secrets and variables > Actions). In this example the secret is called `IBM_IAM_API_KEY`. - -After you have prepared your repository we can get started with two simple examples: the first on how to deploy a Code Engine App and the second one how to deploy a Code Engine Python Function. - -## Deploying an App -Create a directory `my-ce-app` containing the source code you want to deploy to Code Engine. Inside the `my-ce-app` directory create the following files which make up a simple NodeJS Web Server. - -[app.js](https://github.com/IBM/CodeEngine/blob/main/github-action-workflows/my-ce-app/app.js) -```javascript -const express = require("express"); -const app = express(); -const port = 8080; -app.use(express.urlencoded({ extended: true })); -app.use(express.json()); -app.get("/", (req, res) => { - res.setHeader("Content-Type", "application/json"); - res.status(200).send(JSON.stringify({ body: "Hello from Node" })); -}); -const server = app.listen(port, () => { - console.log(`Example app listening at http://localhost:${port}`); -}); -process.on("SIGTERM", () => { - console.info("SIGTERM signal received."); - server.close(() => { - console.log("Http server closed."); - }); -}); -``` - -[package.json](https://github.com/IBM/CodeEngine/blob/main/github-action-workflows/my-ce-app/package.json) -```json -{ - "dependencies": { - "express": "^4.17.1" - } -} -``` -Next, inside of the `.github/workflows` create the following GitHub Action workflow YAML called `deploy-ce-app.yml`. The workflow called `Deploy App to Code Engine` is executed when a push occurs against the `main` branch of the repository. Initially it checks out the repository. In the next step, the `ibm/code-engine-github-action` will be used to deploy the application (component: app) to Code Engine. It uses Code Engine's push feature so we don't need to create the container image ourselves. The deployment will be directed to the project `MY-PROJECT` within your default resource group in the `Frankfurt` region (`eu-de`). The application will be named `my-ce-node-app`, utilizing the content of the `my-ce-app` directory as the source code used for the build step. For more information about Code Engine Push see the [Code Engine Build Docs](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-config-local). - -[deploy-ce-app.yml](https://github.com/IBM/CodeEngine/blob/main/github-action-workflows/my-ce-app/deploy-ce-app.yml) -```yaml -name: Deploy App to Code Engine -on: - push: - branches: - - main -jobs: - app: - runs-on: ubuntu-latest - steps: - - name: Check out code - uses: actions/checkout@v3 - - name: Deploy Application to Code Engine - uses: ibm/code-engine-github-action@v1 - with: - api-key: ${{ secrets.IBM_IAM_API_KEY }} - region: 'eu-de' - project: 'MY-PROJECT' - component: 'app' - name: 'my-ce-app' - build-source: './my-ce-app' -``` -Now, whenever changes are pushed into the `main` branch the Github Action is run and your Code is built and deployed to Code Engine always keeping your Application up to date with your latest changes. - -## Deploying a Python Function -Create a directory `my-ce-py-func` containing your function source code you want to deploy to Code Engine. Inside the `my-ce-py-func` directory create the following files which make up a simple python function. - -[__main__.py](https://github.com/IBM/CodeEngine/blob/main/github-action-workflows/my-ce-py-func/__main__.py) -```python -from lorem_text import lorem - -def main(params): - words = 10 - return { - "headers": { - "Content-Type": "text/plain;charset=utf-8", - }, - "body": lorem.words(words), - } -``` - -[requirements.txt](https://github.com/IBM/CodeEngine/blob/main/github-action-workflows/my-ce-py-func/requirements.txt) -``` -lorem-text -``` -Like the Application example inside of the `.github/workflows` create the following GitHub action Workflow YAML called `deploy-ce-py-func.yml` The workflow called `Deploy Python Function to Code Engine` is executed when a push occurs against the `main` branch of the repository. The `ibm/code-engine-github-action` will be used to deploy the Python Function (component: fn) to Code Engine. The deployment will be directed to the project `MY-PROJECT` within your default resource group in the `Frankfurt` region (eu-de). The Function will be named `my-ce-py-fn`, utilizing the content of the `my-ce-py-func` directory as the source code. - -[deploy-ce-py-func.yml](https://github.com/IBM/CodeEngine/blob/main/github-action-workflows/my-ce-py-func/deploy-ce-py-func.yml) - -```yaml -name: Deploy Python Function to Code Engine -on: - push: - branches: - - main -jobs: - fn-py: - runs-on: ubuntu-latest - steps: - - name: Check out code - uses: actions/checkout@v3 - - name: Deploy Python Function to Code Engine - uses: ibm/code-engine-github-action@v1 - with: - api-key: ${{ secrets.IBM_IAM_API_KEY }} - region: 'eu-de' - project: 'MY-PROJECT' - component: 'fn' - runtime: python-3.11 - name: 'my-ce-py-fn' - build-source: './my-ce-py-func' -``` - -## Conclusion -In this blog, we learned how to create Applications and Functions and automatically deploy them to [IBM Cloud Code Engine] using GitHub Actions as a CI/CD solution. The Code Engine enables developers to effortlessly enhance their development workflows by leveraging a fully managed serverless solution. The workflows depicted above powered by `ibm/codeengine-github-action` simplify and enhance your deployment process and experience. - -Now its up to you! To get started, head on over to [IBM Cloud Code Engine](https://www.ibm.com/products/code-engine) and register for a new account or login to an existing IBM Cloud account and begin your serverless journey with Code Engine. Run your Applications, Jobs or Functions in the Cloud at scale. The documentation, additional information and examples can be found at the included links. - -- [Code Engine](https://cloud.ibm.com/codeengine/overview) -- [Code Engine Docs](https://cloud.ibm.com/codeengine/overview) -- [Example Code](https://github.com/IBM/CodeEngine) -- [Code Engine Github Action](https://github.com/marketplace/actions/code-engine-github-action) -- [Example Source Code](https://github.com/IBM/CodeEngine/tree/main/github-action-workflows) diff --git a/content/posts/From-Markdown-to-live-presentations/featured.jpg b/content/posts/From-Markdown-to-live-presentations/featured.jpg deleted file mode 100644 index aff346c13..000000000 Binary files a/content/posts/From-Markdown-to-live-presentations/featured.jpg and /dev/null differ diff --git a/content/posts/From-Markdown-to-live-presentations/index.md b/content/posts/From-Markdown-to-live-presentations/index.md deleted file mode 100644 index 3c1783a13..000000000 --- a/content/posts/From-Markdown-to-live-presentations/index.md +++ /dev/null @@ -1,108 +0,0 @@ ---- -title: "From Markdown to Live Presentations: Serverless Slidev Deployments with Code Engine Functions and GitHub Actions" -date: 2026-06-22 -description: " Serverless Slidev Deployments with Code Engine Functions and GitHub Actions" -tags: ["serverless", "code engine", "functions", "slidev", "spa", "github actions"] -featureImage: "featured.jpg" -draft: false -authors: ["lukeroy"] ---- - -This post walks through a simple end-to-end workflow for turning a Markdown-based [Slidev](https://sli.dev) deck into a live presentation: create and preview the slides locally, push the project to GitHub, and automatically deploy the generated output to [IBM Cloud Code Engine](https://www.ibm.com/products/code-engine) as a Function using the official [Code Engine GitHub Action](https://github.com/marketplace/actions/code-engine-github-action). - -It builds on our earlier posts [The Serverless Way to Auto-Build and Deploy React, Angular, and Any SPA with IBM Cloud Code Engine Functions](https://ibm.github.io/CodeEngine/posts/serverless-spa-deployment-with-code-engine-functions/) and [IBM Cloud Code Engine: Deploying Apps, Jobs and Functions using GitHub Actions](https://ibm.github.io/CodeEngine/posts/deploying-apps-jobs-and-functions-using-github-actions/), but applies the same approach specifically to Slidev presentations. The result is a clean workflow where you focus on writing slides in Markdown while Code Engine handles the hosting and GitHub Actions handles the deployment. - -[IBM Cloud Code Engine](https://www.ibm.com/products/code-engine) makes this possible by providing a fully managed serverless platform for running applications, jobs, and functions without infrastructure management. In this post, we use a Code Engine Function to serve the static Slidev build as a web presentation, giving you a lightweight way to publish and update slides from your repository. - -By the end, you'll have a repeatable setup that takes your presentation from local authoring to an automatically updated live URL with minimal operational overhead. The same pattern also works for any other SPA or static web content. - - -## What is Slidev? - -[Slidev](https://sli.dev) is a developer-focused presentation framework that lets you write slides entirely in Markdown. Rather than dragging elements around a GUI, you write plain text with a simple syntax—code blocks, headings, lists—and Slidev renders them as polished, interactive slides in the browser. It supports syntax-highlighted code snippets, LaTeX math, custom themes, animations, and even embedded Vue components, making it particularly well-suited for technical talks and developer workshops. - -Under the hood, Slidev compiles your Markdown into a static Single Page Application (SPA) that can be served from any web host. That SPA output is exactly what we'll package and deploy as a Code Engine Function, so every time you push a change to your `slides.md`, a fresh build is triggered and your live presentation URL is updated automatically. - - -## Prerequisites and Setup - -We combine three simple but powerful building blocks to create a seamless, fully automated workflow: Slidev for writing presentations in Markdown, a Code Engine SPA function to serve the presentation as a serverless web application, and GitHub Actions to automate deployment directly from your repository. Together, these enable a setup where you focus purely on content while the platform handles everything else. Slidev allows you to author presentations as Markdown and build them into static web apps, Code Engine Functions take care of building and serving that content without requiring infrastructure management, and GitHub Actions ties it all together with automated CI/CD. - -1. Make sure you have a [IBM Cloud account](https://cloud.ibm.com/) to access Code Engine and related services. For proof-of-concept or initial experimentation, you can simply create an IBM Cloud API key to authenticate your workflows. However, for production-grade setups, it's recommended to use a service ID API key for better security and separation of concerns. To do this, navigate to [Manage → Access (IAM) → Service IDs](https://cloud.ibm.com/iam/serviceids), create a new service ID, assign it access to your resource group along with Code Engine and Container Registry permissions, and then generate and securely store the associated API key for use in your workflows. See the [documentation](https://cloud.ibm.com/docs/iam?topic=iam-serviceidapikeys) for additional information. - -2. Next, set up your GitHub repository by storing your IBM Cloud API key as a secret so it can be securely used by your deployment workflow. Regardless of whether you are using a personal API key or a service ID API key, navigate on GitHub to your repository settings under Settings → Secrets and variables → Actions, create a new secret (for example, `IBM_IAM_API_KEY`), and paste the API key you generated earlier. This allows your GitHub Actions workflow to authenticate with IBM Cloud and deploy your Code Engine function automatically. - -3. Now you can create the project structure.Start by adding the three SPA function wrapper files [main.js](https://github.com/IBM/CodeEngine/blob/main/function-spa/main.js), [package.json](https://github.com/IBM/CodeEngine/blob/main/function-spa/package.json), and [build-spa.sh](https://github.com/IBM/CodeEngine/blob/main/function-spa/build-spa.sh) into the repository directory. These files are the reusable SPA function asset from our [previous post](https://ibm.github.io/CodeEngine/posts/serverless-spa-deployment-with-code-engine-functions/) `build-spa.sh` builds the Slidev project into a static SPA, and `main.js` serves it as a Code Engine Function over HTTP. No changes to these files are needed. - -4. Next, initialize your Slidev project. The following command `npm init slidev@latest my-presentation` generates a `my-presentation` directory containing your `slides.md` file along with the supporting Slidev project files. - -5. Finally, add the GitHub Actions workflow file at `.github/workflows/deploy-func-slides.yml` to enable automated deployment. - -Your directory structure should now look like this: -```bash -├── my-presentation/ # Slidev project -├── main.js # Code Engine function entry point -├── package.json # Runtime dependencies for the function -├── build-spa.sh # Build script executed by Code Engine -└── .github/ - └── workflows/ - └── deploy-func-slides.yml -``` - -Your GitHub Actions workflow should define an automated deployment that builds your Slidev presentation from the repository and deploys it as a Code Engine function whenever changes are pushed to `main`. You simply configure the required parameters such as your API key (`IBM_IAM_API_KEY`), target project, runtime, and source directory so that updates to your repository are automatically reflected in a live deployment. For more details and advanced configuration options, refer to the official Code Engine GitHub Action [documentation](https://github.com/marketplace/actions/code-engine-github-action). - -```yaml -name: Deploy Slidev Presentation to Code Engine - -on: - push: - branches: - - main - -jobs: - - slidev-func: - runs-on: ubuntu-latest - steps: - - name: Check out code - uses: actions/checkout@v3 - - - name: Deploy Presentation Function - uses: IBM/code-engine-github-action@v1 - with: - api-key: ${{ secrets.IBM_IAM_API_KEY }} - region: 'eu-de' # Change to your target region - project: 'my-ce-project' - component: 'fn' - runtime: nodejs-24 - name: 'my-presentation' - build-source: '.' -``` - - -## Creating your Presentations - -With everything set up, you can now focus entirely on creating your presentation. Navigate into the `./my-presentation` directory and open `slides.md` this is the file that contains all of your slides. Each slide is separated by `---` and written in standard Markdown. You can preview your changes locally by running the development server: - -```bash -cd my-presentation -npm run dev -``` - -This provides instant feedback in the browser as you edit. Once you're happy with the result, just commit and push your changes to the `main` branch—your presentation will be automatically rebuilt and deployed, ensuring that what you see locally is exactly what goes live. For more advanced features and customization options, be sure to explore the [Slidev documentation](https://sli.dev/guide/) to create engaging and interactive presentations. - - -## Conclusion - -In summary, this approach creates a fully automated and serverless pipeline where everything—from building to deployment—happens in the background. Every time you update `slides.md` and push your changes, GitHub Actions triggers the workflow, Code Engine builds your Slidev project, and your function is deployed or updated automatically. The result is a streamlined, developer-friendly experience with no manual builds, no infrastructure to manage, and no deployment scripts—just Markdown pushed to GitHub and a live presentation URL moments later. This makes it a great fit for demos, workshops, technical talks, and internal knowledge sharing, and it extends the idea of easy SPA deployment into something even more powerful: turning content itself into the deployment unit. - -Ready to try it yourself? Grab the [SPA function wrapper files](https://github.com/IBM/CodeEngine/tree/main/function-spa) from the Code Engine sample repository, follow the steps above, and have your first Slidev presentation live on Code Engine in under ten minutes. Or check out our other samlples or previous blogs. - -- [Code Engine](https://www.ibm.com/products/code-engine) -- [Code Engine Docs](https://cloud.ibm.com/docs/codeengine) -- [Code Engine Sample Repository](https://github.com/IBM/CodeEngine) -- [Slidev](https://sli.dev/) -- [The Serverless Way to Auto-Build and Deploy React, Angular, and Any SPA with IBM Cloud Code Engine Functions](https://ibm.github.io/CodeEngine/posts/serverless-spa-deployment-with-code-engine-functions/) -- [Code Engine Github Action](https://github.com/marketplace/actions/code-engine-github-action) -- [IBM Cloud Code Engine: Deploying Apps, Jobs and Functions using GitHub Actions](https://ibm.github.io/CodeEngine/posts/deploying-apps-jobs-and-functions-using-github-actions/) -- [IBM Cloud Code Engine GitHub Action: Getting into the Cloud just got a lot easier!](https://ibm.github.io/CodeEngine/posts/getting-into-the-cloud-just-got-a-lot-easier/) \ No newline at end of file diff --git a/content/posts/Getting-into-the-cloud-just-got-a-lot-easier/featured.jpg b/content/posts/Getting-into-the-cloud-just-got-a-lot-easier/featured.jpg deleted file mode 100644 index 14010c10a..000000000 Binary files a/content/posts/Getting-into-the-cloud-just-got-a-lot-easier/featured.jpg and /dev/null differ diff --git a/content/posts/Getting-into-the-cloud-just-got-a-lot-easier/index.md b/content/posts/Getting-into-the-cloud-just-got-a-lot-easier/index.md deleted file mode 100644 index db1198117..000000000 --- a/content/posts/Getting-into-the-cloud-just-got-a-lot-easier/index.md +++ /dev/null @@ -1,245 +0,0 @@ ---- -title: "IBM Cloud Code Engine GitHub Action: Getting into the Cloud just got a lot easier!" -date: 2025-11-26 -description: "Getting into the Cloud just got a lot easier!" -tags: ["serverless", "code engine", "github actions"] -featureImage: "featured.jpg" -draft: false -authors: ["lukeroy"] ---- - -## Introduction - -[IBM Cloud Code Engine](https://www.ibm.com/products/code-engine) is IBM’s fully managed, strategic serverless platform that lets you run container images, batch jobs, source code, and functions in the cloud — without worrying about infrastructure management or scalability. It’s designed to simplify cloud-native development so you can focus on building, your business logic, not managing infrastructure. To make the developer experience even smoother, we introduced the [IBM Cloud Code Engine GitHub Action](https://github.com/IBM/code-engine-github-action). This action allows you to automate the build and deployment of your apps, jobs, and functions directly to Code Engine from your GitHub workflows. - -And now, it just got even better! - -We’re excited to announce new capabilities that take automation and flexibility to the next level: - -### Build from Source with Ease: -The action now supports building a container image directly from your source code and storing it in [IBM Cloud Container Registry](https://www.ibm.com/products/container-registry) — ready for deployment. - -### Multiple Build Strategies: - -- Buildpacks (default): No Dockerfile required! Perfect for quick builds without extra configuration. -- Dockerfile: For developers who want full control over their build process. - -### Image Support for Apps and Jobs: -Instead of building and deploying every time, you can now reference existing container images, including private ones. This opens the door to advanced workflows, such as multi-stage builds or integrating with external CI/CD pipelines. - -With these enhancements, getting your workloads into the cloud has never been easier — or more powerful. - -## Getting Started - -Before diving into the examples, it’s important to prepare your repository for seamless integration with IBM Cloud Code Engine. Here’s what you need to do: - -## Prerequisites - -First, enable GitHub Actions for your repository. This can be done an a per repository basis. If your repository isn’t already enabled for GitHub Actions, check your access permissions, and reach out to the administrator of the GitHub organization. - -## IBM Cloud account preparations - -If you’re building a proof of concept or trying out the Code Engine for the first time, create an [IBM Cloud API Key](https://cloud.ibm.com/iam/apikeys) to authenticate your workflows with IBM Cloud services. For production-grade workloads create an IBM Cloud service ID API Key to authenticate your workflows with IBM Cloud services, as described below: - -- Navigate to [Manage → Access (IAM) → Service IDs](https://cloud.ibm.com/iam/serviceids) . -- Click Create service ID, give it a name, assign Access policies to `Resource group only`, `Code Engine` and `Container Registry`. Then create a API key and copy the generated key for later use. See the [documentation](https://cloud.ibm.com/docs/iam?topic=iam-serviceidapikeys) for additional information. - -Regardless whether you are using a personal API Key, or a service ID API Key, store it’s value as a GitHub secret: - -- On GitHub.com, navigate to your repository and go to Settings → Secrets and variables → Actions. -- Create a new secret named `IBM_IAM_API_KEY` (or any name you prefer) and paste the API key you've generated. - -Congratulations, your repository is now ready to leverage the IBM Cloud Code Engine GitHub Action. Let’s move on to the exciting part — exploring the new functionalities with hands-on examples! This blog post, uses pretty simple hello world examples. If you’re looking for more advanced code examples and sample workflows, be sure to check out the [Code Engine Sample Repository](https://github.com/IBM/CodeEngine), or revisit my initial blogpost [IBM Cloud Code Engine: Deploying Apps, Jobs and Functions using GitHub Actions](https://medium.com/@luke.roy/ibm-cloud-code-engine-deploying-apps-jobs-and-functions-using-github-actions-76de1f8352a3) that showcased the Code Engine GitHub Action. - -## Building and Pushing a Container Image to IBM Container Registry (ICR) Using Code Engine: - -Start by creating a directory my-ce-app containing the source code you want to build and push to ICR using Code Engine build run. Inside the my-ce-app directory create the following files which make up a simple Node.JS Web Server. - -`app.js` - -```javascript -const express = require("express"); -const app = express(); -const port = 8080; -app.use(express.urlencoded({ extended: true })); -app.use(express.json()); -app.get("/", (req, res) => { - res.setHeader("Content-Type", "application/json"); - res.status(200).send(JSON.stringify({ body: "Hello from Node" })); -}); -const server = app.listen(port, () => { - console.log(`Example app listening at http://localhost:${port}`); -}); -process.on("SIGTERM", () => { - console.info("SIGTERM signal received."); - server.close(() => { - console.log("Http server closed."); - }); -}); -``` - -`package.json` - -```json -{ - "dependencies": { - "express": "^4.17.1" - } -} -``` - -`build-push.yml` - -```yaml -name: Build and Push to ICR - -on: - push: - branches: - - main -jobs: - app: - runs-on: ubuntu-latest - steps: - - name: Check out code - uses: actions/checkout@v3 - - name: Build and Push to ICR - id: build-step - uses: ibm/code-engine-github-action@v1 - with: - api-key: ${{ secrets.IBM_IAM_API_KEY }} - region: 'eu-de' - project: 'MY-PROJECT' - component: 'build' - name: 'my-ce-app' - image: private.de.icr.io/my-namespace/my-image:latest - registry-secret: ce-auto-icr-private-eu-de - build-source: './my-ce-app' - - name: Get image with digest - run: | - echo "Image with digest: ${{ steps.build-step.outputs.image-with-digest }}" -``` - -Next, inside of the `.github/workflows` create the following GitHub Action workflow YAML called `build-push.yml`. The workflow called "Build and Push to ICR" is executed when a push occurs against the main branch of the repository. Initially, it checks out the repository. In the next step, the `ibm/code-engine-github-action` will be used to build the container image (component: build) using Code Engine build run functionality and push the resulting container image to private ICR in `eu-de` using the auto generated registry secret created by Code Engine this can be omitted as this is the default value for the Code Engine GitHub Action. The build will be directed to the project `MY-PROJECT` within your default resource group in the Frankfurt region (`eu-de`). The build run will be named `my-ce-build` appended with the current timestamp the resulting image will be named `private.de.icr.io/my-namespace/my-image:latest`, utilizing the content of the `my-ce-app` directory as the source code used for the build step. The image refrerence and its digest is outputted for use in subsequent steps using `${{ steps.build-step.outputs.image-with-digest }}`. For more information about Code Engine Push see the [Code Engine Build Docs](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-standalone). - -**Please note**: The example depicted above uses `my-namespace` as the IBM Container Registry namespace. As namespaces are unique, you'll need to use your own one. - -## Building and Deploying Your Code Engine App Using the Dockerfile Build Strategy - -If you need more control over the build process -- such as adding custom dependencies, performance optimzation, or fine-tuning configurations -- the Dockerfile build strategy is the way to go. Unlike buildpacks, which handle most of the heavy lifting automatically, Dockerfile gives you full flexibility for advanced use cases. -Start by organizing your application source (main.go) code and a Dockerfile inside the `my-docker-app` directory. This directory will contain everything needed to build your container image. - -`main.go` - -```golang -package main -import ( - "fmt" - "net/http" - "time" -) -func greet(w http.ResponseWriter, r *http.Request) { - fmt.Fprintf(w, "Hello World! %s", time.Now()) -} -func main() { - http.HandleFunc("/", greet) - http.ListenAndServe(":3000", nil) -} -``` - -`Dockerfile` - -```dockerfile -FROM quay.io/projectquay/golang:1.24 AS build-env -WORKDIR /go/src/app -COPY main.go main.go -RUN CGO_ENABLED=0 go build -o /go/bin/app main.go -FROM gcr.io/distroless/static-debian12 -EXPOSE 3000 -COPY --from=build-env /go/bin/app / -ENTRYPOINT ["/app"] -``` - -`build-dockerfile-app.yml` - -```yaml -name: Deploy App to Code Engine using Dockerfile build-strategy -on: - push: - branches: - - main - workflow_dispatch: -jobs: - deploy-app: - runs-on: ubuntu-latest - steps: - - name: Check out code - uses: actions/checkout@v3 - - name: Deploy App to Code Engine using Dockerfile build-strategy - uses: IBM/code-engine-github-action@v1 - with: - api-key: ${{ secrets.IBM_IAM_API_KEY }} - resource-group: 'Default' - region: 'eu-de' - project: 'MY-PROJECT' - component: 'app' - build-strategy: 'dockerfile' - port: 3000 - name: 'my-docker-app' - build-source: './my-docker-app' - cpu: 1 - memory: 4G -``` - -Next, navigate to the `.github/workflows directory` and create a new GitHub Actions workflow file named `build-dockerfile-app.yml`. This workflow is responsible for automating the build and deployment process for your application. Specifically, it will use IBM Cloud Code Engine to build the application from the source code located in the my-docker-app directory, leveraging the provided Dockerfile to create the container image. Once the image is successfully built, the workflow will deploy it as a Code Engine application, ensuring a streamlined and reproducible CI/CD pipeline. - -## Deploying an Existing Container Image to Code Engine as an Application - -If you already have a container image built elsewhere -- perhaps as part of another CI/CD pipeline or stored in a private registry -- you can now deploy it directly to IBM Cloud Code Engine without rebuilding. This feature is perfect for teams that want to reuse pre-built images or integrate Code Engine into existing workflows. -Inside of the `.github/workflows` create the following GitHub Action workflow YAML called `my-img-app.yml`. Instead of specifying source code or a build strategy, you reference the container image you want to deploy. This can be an image stored in IBM Container Registry (ICR) or any other registry, including private ones. We will be using the Code Engine Hello World image: `icr.io/codeengine/helloworld:latest`. In your workflow configuration, you’ll define key parameters like the project name, region, and resource group, along with the image reference and application settings (such as CPU and memory). Once triggered -- either on a push to the main branch or manually -- the workflow will deploy your application to Code Engine using the specified image. - -`my-img-app.yml` - -```yaml -name: Deploy Application to Code Engine using existing container image -on: - push: - branches: - - main - workflow_dispatch: -jobs: - deploy-app: - runs-on: ubuntu-latest - steps: - - name: Check out code - uses: actions/checkout@v3 - - name: Deploy Application to Code Engine using existing container image - uses: IBM/code-engine-github-action@v1 - with: - api-key: ${{ secrets.IBM_IAM_API_KEY }} - resource-group: 'Default' - region: 'eu-de' - project: 'MY-PROJECT' - component: 'app' - name: 'my-img-app' - image: icr.io/codeengine/helloworld:latest - cpu: 1 - memory: 4G -``` - -These examples highlight how the new GitHub Action features make it easier to automate builds, manage deployments, and create advanced workflows for your cloud-native applications. - -## Conclusion - -The IBM Cloud Code Engine GitHub Action makes deploying cloud-native workloads easier, faster, and more flexible than ever before. With support for multiple build strategies, image-based deployments, and seamless integration with GitHub Actions, you can automate your entire build-and-deploy pipeline without leaving your development workflow. - -Whether you’re building from source using buildpacks, fine-tuning with a Dockerfile, or deploying pre-built images from your registry, these new capabilities empower you to create advanced CI/CD workflows tailored to your needs. No more manual steps — just streamlined automation that gets your applications, jobs, and functions running in the cloud with minimal effort. - -Getting into the cloud has never been this easy — so why wait? Start automating your deployments now! - -- [Code Engine](https://www.ibm.com/products/code-engine) -- [Code Engine Docs](https://cloud.ibm.com/docs/codeengine) -- [Example Code](https://github.com/IBM/CodeEngine) -- [Code Engine Github Action](https://github.com/marketplace/actions/code-engine-github-action) -- [Example Source Code](https://github.com/IBM/CodeEngine/tree/main/github-action-workflows) -- [IBM Cloud Code Engine: Deploying Apps, Jobs and Functions using GitHub Actions](https://medium.com/@luke.roy/ibm-cloud-code-engine-deploying-apps-jobs-and-functions-using-github-actions-76de1f8352a3) \ No newline at end of file diff --git a/content/posts/Running-Binaries-inside-ibm-cloud-code-engine-function-runtimes/featured.jpg b/content/posts/Running-Binaries-inside-ibm-cloud-code-engine-function-runtimes/featured.jpg deleted file mode 100644 index c6c8bb616..000000000 Binary files a/content/posts/Running-Binaries-inside-ibm-cloud-code-engine-function-runtimes/featured.jpg and /dev/null differ diff --git a/content/posts/Running-Binaries-inside-ibm-cloud-code-engine-function-runtimes/index.md b/content/posts/Running-Binaries-inside-ibm-cloud-code-engine-function-runtimes/index.md deleted file mode 100644 index 6549a04d2..000000000 --- a/content/posts/Running-Binaries-inside-ibm-cloud-code-engine-function-runtimes/index.md +++ /dev/null @@ -1,129 +0,0 @@ ---- -title: "IBM Cloud Code Engine: Running Binaries inside the IBM Cloud Code Engine Function Runtimes" -date: 2025-01-30 -description: "Dunning Binaries inside the IBM Cloud Code Engine Function Runtimes" -tags: ["serverless", "code engine", "functions"] -featureImage: "featured.jpg" -draft: false -authors: ["lukeroy"] ---- - -In this blog post, we’ll explore how you can use [IBM Cloud Code Engine](https://www.ibm.com/de-de/products/code-engine) to run binaries inside the existing Node.js and Python runtimes. - -IBM Cloud Code Engine is IBMs Strategic serverless compute platform that supports a variety of workloads including functions. A function is a stateless code snippet, that perform tasks as it is invoked by HTTP. For Functions, Code Engine currently supports two programming languages: Node.js and Python. But what if you prefer to use a different language? - -The solution lies in utilizing one of the existing runtimes, which is provided by IBM Cloud Code Engine. and bundling and executing a binary. In this example, we’ll create a simple function using the Python runtime which will run (`subprocess.run`), a binary written in Go. We’ll leverage the ability to add the binary to the function’s code bundle during the build process. - - -1. Start by writing a Python function that acts as a wrapper to execute the binary. This wrapper can take the functions parameters and serialize them into a JSON string. The wrapper function will then run the binary, passing the JSON string as a command-line argument. The binary’s output, which will be in JSON format, will be captured and deserialized into a Python dictionary. Finally, this dictionary will be returned as the result of the wrapper function invocation. - -`__main__.py` - -```python -import subprocess -import json - -output_dict={} -statusCode = 0 -binary="my-program" - -def main(params): - command = f'./{binary} \'{json.dumps(params)}\'' - result = subprocess.run(command, shell=True, capture_output=True, text=True) - - if result.returncode == 0: - statusCode = 200 - output_dict = json.loads(result.stdout) - else: - statusCode = 500 - output_dict = {"error":"an error as occured"} - - return { - "headers": { - 'Content-Type': 'application/json; charset=utf-8', - }, - "statusCode": statusCode, - "body": output_dict, - } -``` -2. Implement the logic of your application in a Go source file (or multiple). The Go binary must be designed to handle input and output in JSON format. In this example, it should receive a JSON object that contains a key, such as “name”, and return a JSON object that includes the provided value along with additional data. This ensures a clear and consistent interface between the wrapper function and the Go binary. It is up to you to add whatever real world functionality you need inside the Go Code. - -`main.go` - -```golang -package main - -import ( - "encoding/json" - "fmt" - "os" -) - -type Response struct { - Key string `json:"key"` - Value string `json:"value"` - Data interface{} `json:"data"` -} - -func main() { - // recive data as json string and unmarshal into variable - var inputData map[string]interface{} - if len(os.Args) > 1 { - jsonString := os.Args[1] - err := json.Unmarshal([]byte(jsonString), &inputData) - if err != nil { - os.Exit(1) - } - } - - // Here comes your logic - name := "placeholder" - if len(inputData) != 0 { - name = inputData["name"].(string) - } - - // return the response json (to the python code) - respones := Response{ - Key: "New Key", - Value: name, - Data: inputData, - } - responseJSON, err := json.Marshal(respones) - if err != nil { - os.Exit(1) - } - fmt.Println(string(responseJSON)) -} -```` - -3. If deploying this setup from the directory where the Go source code is stored, create a `.ceignore` file. This file ensures that only the compiled binary, and not the raw Go source code is included in the function code bundle. This step is useful to exclude any unnecessary files. - -`.ceignore` - -``` -main.go -``` - -4. Compile your Go source code into a Go binary. Ensure the build is configured for the target architecture and operating system, for Code Engine this is `linux/amd64`. Proper compilation ensures compatibility and prevents runtime errors. - -```bash -GOOS=linux GOARCH=amd64 go build -o "my-program" -ldflags="-s -w" ./main.go -``` - -Your directory should look like this: -```bash -├── __main__.py -├── main.go -├── .ceignore -└── my-program -``` - -5. Create your code engine function using the [IBM Cloud Code Engine CLI](https://cloud.ibm.com/docs/codeengine?topic=codeengine-cli) Make sure the binary is in the same directory as the Python function code `__main__.py`. After running the command you will have a code engine function which will execute your go binary as part of the function logic. - -```bash -ibmcloud ce fn create - name - runtime python-3.11 - build-source . -``` - -6. You can now call your function using the displayed URL - -And that’s it! You have now successfully created a IBM Code Engine Function by deploying your Python wrapper code and your Go binary and executed it on the IBM Cloud. \ No newline at end of file diff --git a/content/posts/Upscaling-videos-ibm-cloud-code-engine-serverless-fleets/featured.jpg b/content/posts/Upscaling-videos-ibm-cloud-code-engine-serverless-fleets/featured.jpg deleted file mode 100644 index eb7f3193d..000000000 Binary files a/content/posts/Upscaling-videos-ibm-cloud-code-engine-serverless-fleets/featured.jpg and /dev/null differ diff --git a/content/posts/Upscaling-videos-ibm-cloud-code-engine-serverless-fleets/index.md b/content/posts/Upscaling-videos-ibm-cloud-code-engine-serverless-fleets/index.md deleted file mode 100644 index 06ba2e643..000000000 --- a/content/posts/Upscaling-videos-ibm-cloud-code-engine-serverless-fleets/index.md +++ /dev/null @@ -1,74 +0,0 @@ ---- -title: "Upscaling Videos with IBM Cloud Code Engine Serverless Fleets" -date: 2025-10-07 -description: "Upscaling Videos with IBM Cloud Code Engine Serverless Fleets" -tags: ["serverless", "code engine", "GPU", "AI", "serverless fleets", ] -featureImage: "featured.jpg" -draft: false -authors: ["lukeroy"] ---- - -[IBM Cloud Code Engine](https://www.ibm.com/products/code-engine) is IBM’s fully managed, strategic serverless platform that empowers developers to run container images, batch jobs, source code, and functions — all in one unified environment. It abstracts away the complexity of infrastructure management, automatically handling scaling, networking, and security so you can focus on building and deploying your applications. -With the introduction of [Serverless Fleets](https://www.ibm.com/new/announcements/ibm-cloud-code-engine-introduces-serverless-fleets-with-gpus), IBM Cloud Code Engine now supports large-scale, parallel execution of run-to-completion tasks across multiple virtual machines — securely hosted within your own [Virtual Private Cloud](https://www.ibm.com/solutions/vpc) (VPC). This gives you the flexibility to define custom subnets and choose from a wide range of [Virtual Server Instance](https://www.ibm.com/products/virtual-servers) (VSI) flavors, including GPU-enabled options, tailored to your workload’s performance needs. -What sets Code Engine apart is its serverless nature — it abstracts away the operational complexity of infrastructure management. You don’t need to worry about provisioning, scaling, or securing the underlying compute resources. Instead, you can focus entirely on your application logic and task definitions, while Code Engine handles the orchestration behind the scenes. -By running Code Engine Serverless Fleets in a single-tenant environment, you gain enhanced control over performance, security, and compliance. This architecture ensures that your workloads execute in isolated infrastructure, making it ideal for enterprise-grade use cases such as video processing, AI inference, and scientific computing — all with a streamlined developer experience. Check out the [introduction](https://www.ibm.com/new/announcements/ibm-cloud-code-engine-introduces-serverless-fleets-with-gpus) to Code Engine Serverless Fleets or look at the [documentation](https://cloud.ibm.com/docs/codeengine?topic=codeengine-cefleets). - -In this blog post, we’ll explore a hands-on use case: upscaling video files using the [Video2X](https://docs.video2x.org/) framework powered by Real-ESRGAN, orchestrated entirely through IBM Cloud Code Engine Serverless Fleets with GPU support. - -To follow along with this tutorial, you’ll need to have several IBM Cloud resources set up. These include an activated [IBM Cloud account](https://cloud.ibm.com/login), a [Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-getting-started) project, and an [IBM Cloud Object Storage](https://www.ibm.com/products/cloud-object-storage) instance configured with three COS buckets, each supporting built-in encryption and multi-region capabilities. The first bucket stores the data required to run your IBM Cloud Code Engine Serverless Fleets, the second holds the input files used by the fleet, and the third one is used to store the output files. Additionally, you’ll need a Virtual Private Cloud (VPC) with appropriately configured subnets. - -To simplify the setup process, we’ll be using a one-time configuration script available in the following [GitHub repository](https://github.com/IBM/CodeEngine/tree/main/serverless-fleets), which automatically provisions and configures all the required IBM Cloud resources. This approach is ideal for users who are new to Code Engine Serverless Fleets or want a [quick start](https://github.com/IBM/CodeEngine/tree/main/serverless-fleets#one-time-setup). However, if you’re already familiar with Code Engine and have an existing environment, feel free to customise or integrate the example setup to suit your current infrastructure. - - -## Upscaling the videos - -Now that all the prerequisites for running Serverless Fleets on IBM Cloud Code Engine are in place, we can begin preparing our video upscaling use case. Start by uploading your video files to the designated COS input bucket. You can use the IBM Cloud UI, or any tool you’re comfortable with — such as rclone or other file transfer utilities. For consistency, we’ll store the uploaded videos in the COS input bucket using the prefix `/videos`. Once processed, the upscaled output files will be saved in the COS output bucket, also under the `/videos` prefix. This structure helps keep your input and output data organized and easy to manage. -Become a Medium member - -With your video files now available in the COS input bucket, the next step is to create a `videos.jsonl` file. This file serves as a task list for the fleet, where each line contains a JSON object that defines how a specific video should be processed. Each task entry includes the necessary metadata and instructions for handling one video. For example, if you have eight videos to upscale, your `videos.jsonl` file might look something like this, with one line per video task. - -```json -{ "args": ["--input", "/input/video-1.mp4", "--output", "/output/video-1-upscale.mp4", "--processor", "realesrgan", "--scaling-factor", "4", "--realesrgan-model","realesrgan-plus"]} -{ "args": ["--input", "/input/video-2.mp4", "--output", "/output/video-2-upscale.mp4", "--processor", "realesrgan", "--scaling-factor", "4", "--realesrgan-model","realesrgan-plus"]} -{ "args": ["--input", "/input/video-3.mp4", "--output", "/output/video-3-upscale.mp4", "--processor", "realesrgan", "--scaling-factor", "4", "--realesrgan-model","realesrgan-plus"]} -{ "args": ["--input", "/input/video-4.mp4", "--output", "/output/video-4-upscale.mp4", "--processor", "realesrgan", "--scaling-factor", "4", "--realesrgan-model","realesrgan-plus"]} -{ "args": ["--input", "/input/video-5.mp4", "--output", "/output/video-5-upscale.mp4", "--processor", "realesrgan", "--scaling-factor", "4", "--realesrgan-model","realesrgan-plus"]} -{ "args": ["--input", "/input/video-6.mp4", "--output", "/output/video-6-upscale.mp4", "--processor", "realesrgan", "--scaling-factor", "4", "--realesrgan-model","realesrgan-plus"]} -{ "args": ["--input", "/input/video-7.mp4", "--output", "/output/video-7-upscale.mp4", "--processor", "realesrgan", "--scaling-factor", "4", "--realesrgan-model","realesrgan-plus"]} -{ "args": ["--input", "/input/video-8.mp4", "--output", "/output/video-8-upscale.mp4", "--processor", "realesrgan", "--scaling-factor", "4", "--realesrgan-model","realesrgan-plus"]} -``` - -Explanation of Parameters: - -- **--input**: Path to the input video file (input bucket mounted from COS) -- **--output**: Path where the upscaled video will be saved (output bucket mounted from COS) -- **--processor**: Specifies the upscaling engine (e.g. realesrgan) -- **--scaling-factor**: Determines the upscale factor (e.g., 2x, 4x) -- **--realesrgan-model**: Chooses the model variant (e.g., realesrgan-plus for live-action content) - -Dive into the [Video2X GitHub repository](https://github.com/k4yt3x/video2x/) and its [documentation](https://docs.video2x.org/) to explore alternative engines and models. This will allow you to fine-tune processing parameters and achieve optimal upscaling results tailored to your specific use case. - -Now that your videos and tasks are prepared, it’s time to launch the fleet using IBM Cloud Code Engine. You can do this via the Code Engine UI or the CLI. In this example, we’ll use the CLI to run the Code Engine Serverless Fleets with the official Video2X container image (`ghcr.io/k4yt3x/video2x:6.4.0`). The Code Engine Serverless Fleets will be configured to process tasks defined in the `videos.jsonl` file, with two tasks running in parallel. Of course, this setup is fully customizable—you can scale the number of concurrent tasks, adjust resource allocations, and process as many videos as you upload and define. -Each task will be allocated substantial resources -- `20 CPU cores`, `100 GB of RAM`, and an `NVIDIA L40 GPU` -- ensuring high-performance video upscaling. Since the maximum scale is set to two, Code Engine will provision two worker VSIs to handle the tasks concurrently, with each worker processing one video at a time. -The `--tasks-state-store` parameter points to a persistent COS bucket used to manage the operational state of the Code Engine Serverless Fleets. Additionally, the `--mount-data-store` options mount the input and output COS buckets into the container: the input bucket with the prefix `/videos` is mounted at `/input`, and the output bucket with the prefix `/videos` is mounted at the path `/output` inside the container. - -```bash -ibmcloud code-engine fleet create --name “upscale-videos” \ ---image "ghcr.io/k4yt3x/video2x:6.4.0" \ ---max-scale 2 \ ---tasks-from-local-file videos.jsonl \ ---gpu l40s \ ---cpu 20 \ ---memory 100G \ ---tasks-state-store fleet-task-store \ ---mount-data-store /input=fleet-input-store:/videos \ ---mount-data-store /output=fleet-output-store:/videos -``` - -## Conclusion - -Upscaling videos using IBM Cloud Code Engine Serverless Fleets showcases the power and flexibility of modern serverless architectures for high-performance, GPU-accelerated workloads. By combining the simplicity of Code Engine with the scalability of Serverless Fleets and the efficiency of the Video2X framework, developers can process large volumes of media files in parallel — without the burden of managing infrastructure. -This hands-on example demonstrates how easy it is to orchestrate complex tasks like video upscaling in a secure, isolated environment using IBM Cloud Code Engine Serverless Fleets. From provisioning resources with a one-time setup script to defining tasks in a structured `videos.jsonl` file and executing them with fine-tuned compute configurations, the entire workflow is streamlined for productivity and performance. -Whether you're working on media processing, AI inference, or scientific workloads, IBM Cloud Code Engine Serverless Fleets provides a robust and developer-friendly solution. With support for GPU-enabled VSIs, customisable networking, and seamless integration with IBM Cloud Object Storage, you can build scalable, enterprise-grade pipelines with minimal operational overhead. -Ready to take it further? Dive into the Video2X GitHub repository to explore various models and fine-tune parameters to suit your needs. Start building your own Code Engine Serverless Fleet powered video processing workflows on IBM Cloud today. -While you're at it, be sure to also check out the other powerful components of Code Engine -- [Applications](https://cloud.ibm.com/docs/codeengine?topic=codeengine-application-workloads), [Jobs](https://cloud.ibm.com/docs/codeengine?topic=codeengine-job-plan), and [Functions](https://cloud.ibm.com/docs/codeengine?topic=codeengine-fun-work) -- as well as additional Serverless Fleets use cases like Batch Inferencing, Docling, and Monte Carlo Simulation available in the [sample repository](https://github.com/IBM/CodeEngine/). \ No newline at end of file diff --git a/content/posts/Why-ibm-cloud-code-engine-is-the-perfect-home-for-linuxserverio-application/app-create-1.jpg b/content/posts/Why-ibm-cloud-code-engine-is-the-perfect-home-for-linuxserverio-application/app-create-1.jpg deleted file mode 100644 index 9c97ca7b1..000000000 Binary files a/content/posts/Why-ibm-cloud-code-engine-is-the-perfect-home-for-linuxserverio-application/app-create-1.jpg and /dev/null differ diff --git a/content/posts/Why-ibm-cloud-code-engine-is-the-perfect-home-for-linuxserverio-application/app-create-2.jpg b/content/posts/Why-ibm-cloud-code-engine-is-the-perfect-home-for-linuxserverio-application/app-create-2.jpg deleted file mode 100644 index 46ee9be3d..000000000 Binary files a/content/posts/Why-ibm-cloud-code-engine-is-the-perfect-home-for-linuxserverio-application/app-create-2.jpg and /dev/null differ diff --git a/content/posts/Why-ibm-cloud-code-engine-is-the-perfect-home-for-linuxserverio-application/ce-pds.jpg b/content/posts/Why-ibm-cloud-code-engine-is-the-perfect-home-for-linuxserverio-application/ce-pds.jpg deleted file mode 100644 index 21dbaae8d..000000000 Binary files a/content/posts/Why-ibm-cloud-code-engine-is-the-perfect-home-for-linuxserverio-application/ce-pds.jpg and /dev/null differ diff --git a/content/posts/Why-ibm-cloud-code-engine-is-the-perfect-home-for-linuxserverio-application/ce-volume-mount.jpg b/content/posts/Why-ibm-cloud-code-engine-is-the-perfect-home-for-linuxserverio-application/ce-volume-mount.jpg deleted file mode 100644 index d09f4b947..000000000 Binary files a/content/posts/Why-ibm-cloud-code-engine-is-the-perfect-home-for-linuxserverio-application/ce-volume-mount.jpg and /dev/null differ diff --git a/content/posts/Why-ibm-cloud-code-engine-is-the-perfect-home-for-linuxserverio-application/featured.jpg b/content/posts/Why-ibm-cloud-code-engine-is-the-perfect-home-for-linuxserverio-application/featured.jpg deleted file mode 100644 index 1740a7924..000000000 Binary files a/content/posts/Why-ibm-cloud-code-engine-is-the-perfect-home-for-linuxserverio-application/featured.jpg and /dev/null differ diff --git a/content/posts/Why-ibm-cloud-code-engine-is-the-perfect-home-for-linuxserverio-application/index.md b/content/posts/Why-ibm-cloud-code-engine-is-the-perfect-home-for-linuxserverio-application/index.md deleted file mode 100644 index 4e87182f9..000000000 --- a/content/posts/Why-ibm-cloud-code-engine-is-the-perfect-home-for-linuxserverio-application/index.md +++ /dev/null @@ -1,128 +0,0 @@ ---- -title: "Why IBM Cloud Code Engine Is the Perfect Home for LinuxServer.io Applications" -date: 2025-09-29 -description: "Why IBM Cloud Code Engine Is the Perfect Home for LinuxServer.io Applications" -tags: ["serverless", "code engine", "functions", "typescript"] -featureImage: "featured.jpg" -draft: false -authors: ["lukeroy"] ---- - -[LinuxServer.io](https://www.linuxserver.io/) is a global community of open-source enthusiasts who maintain one of the most extensive collections of standardized Docker images. These images are designed with simplicity, consistency, and transparency in mind — making them ideal for everyone from curious beginners to seasoned self-hosters. Whether you’re looking to run a media server, a productivity tool, or a creative application, LinuxServer.io offers a rich catalog of ready-to-use containers that are well-documented and regularly updated. Just deploy an image, and you can access the application directly in your browser — no complex setup required. - -But where should you run these powerful, community-maintained applications? - -Simple, [IBM Cloud Code Engine](https://www.ibm.com/products/code-engine)! IBM’s fully managed, strategic serverless platform makes deploying and running functions, containers, batch jobs and web apps effortless. With Code Engine, you don’t need to worry about provisioning infrastructure, managing servers, or scaling workloads. It automatically handles all of that for you, allowing applications to scale up when needed and scale down to zero when idle, saving you time, money, and complexity. - -## A Match Made in the Cloud - -Pairing LinuxServer.io with IBM Cloud Code Engine creates a seamless experience for anyone, be it developers, hobbyists, educators, or even small business owners. Whoever wants to run powerful applications in the cloud without the overhead of traditional infrastructure has come to the right place. - -- **No DevOps Required:** You don’t need to be a cloud expert to deploy LinuxServer.io containers on Code Engine. Code Engine handles scaling, networking, and resource management automatically. -- **Cost-Efficient:** Thanks to Code Engine’s scale-to-zero feature, your applications only consume resources when they’re actively used. -- **Secure and Customizable:** Easily add environment variables to configure access controls and personalize your deployments. -- **Flexible Access:** Use either the intuitive web UI or the CLI to deploy and manage your applications. - -## Explore the Possibilities - -LinuxServer.io offers containers for a wide range of use cases: - -- **Productivity:** LibreOffice, WPS Office, FileZilla… -- **Creativity:** Blender, Audacity, kdenlive, gimp… -- **Media & Reading:** Jellyfin (Media Server), Calibre (eBook management) … -- **Web Browsing:** Chrome, Firefox… -- **Development Tools:** Visual Studio Code… -- **Gaming:** SteamOS, retroarch, dolphin… - -You can browse the full catalog of nearly 200 container images here: [https://www.linuxserver.io/our-images](https://www.linuxserver.io/our-images) - -## Getting Started with Code Engine - -Before deploying your first container, make sure you have the following prerequisites: A activated [IBM Cloud Account](https://cloud.ibm.com/login) and a Code Engine Project in your preferred region. If you want to do this in the CLI make sure to install the [IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-getting-started) and [Code Engine Plugin](https://cloud.ibm.com/docs/codeengine?topic=codeengine-cli). - -## Deploying a LinuxServer.io Container via CLI - -Here’s how simple it is to deploy Blender using the Code Engine CLI. Specifly your apps name, the port the image that should be used and as a nice bonus each linuxserver.io image comes with Basic Auth which can be configured using the to environment variables `CUSTOM_USER` and `PASSWORD`. This ensures that only you have access to your applications—no complex setup required: - -```bash -ibmcloud ce app create \ ---name linuxserver-blender \ ---port 3000 \ ---image lscr.io/linuxserver/blender:latest \ ---env CUSTOM_USER="myuser" \ ---env PASSWORD="mypwd" -``` - -Once deployed, Code Engine will provide a secure URL to access your Blender instance. That’s it — your container is live and ready to use! - -## Deploying via the IBM Cloud UI - -Prefer a visual approach? No problem. Navigate to your Code Engine project : Containers → Serverless Project → your-project → App. Then click the Create button and a creation form for you app will open. Fill in the following values: - -- **Application Name** -- **Container Image** (e.g., lscr.io/linuxserver/chrome:latest) -- **Port** (usually 3000 for LinuxServer images) -- **Environment Variables** (CUSTOM_USER, PASSWORD) - -![LinuxServer.io App create 1](app-create-1.jpg) -![LinuxServer.io App create 2](app-create-2.jpg) - -Click Create, and your application will be up and running within minutes. Once deployed, simply grab the URL to access your app directly in your browser — no extra configuration needed. -Become a Medium member - -Now that you know how easy it is to deploy containers, feel free to explore and run any other LinuxServer.io image. Just create a new application using the desired image, and you’re good to go! - -## Extending Functionality with Persistent Storage - -Now that we’ve covered the basics of deploying LinuxServer.io containers on IBM Cloud Code Engine, let’s explore how to add **persistent storage** using a **[IBM Cloud Object Storage (COS)](https://www.ibm.com/products/cloud-object-storage) bucket** — with built-in encryption and multi-region support. This feature is especially useful for applications that need to save files across sessions — like office suites, media editors, or file managers. By mounting a COS bucket directly into your running container, you gain a secure, scalable, and high-performance location to store and retrieve data. To proceed with this section, make sure you’ve completed the optional setup steps: creating a COS bucket and configuring a persistent data store within your Code Engine project. - -To set up a persistent data storage using IBM Cloud Object Storage (COS) with Code Engine, start by creating a COS instance and bucket, then generate HMAC credentials. See the following [documentation](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-getting-started-cloud-object-storage) for setting up COS. Use these credentials to create a [HMAC secret in Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-secret#secret-create-ui-hmac), which you’ll reference when configuring a persistent data store for your COS bucket as described at the followin [Code Engine documentation](https://cloud.ibm.com/docs/codeengine?topic=codeengine-persistent-data-store&interface=ui). - -After you have created your COS instance, bucket and HMAC credentials you can use the following Code Engine CLI commands to create your secret and persistent data store. - -```bash -ibmcloud ce secret create \ ---name cos-hmac-secret \ ---access-key-id \ ---secret-access-key -``` - -```bash -ibmcloud ce pds create \ ---name my-cos-pds \ ---cos-access-secret cos-hmac-secret \ ---cos-bucket-name -``` - -For example, deploying **WPS Office** with persistent storage via the CLI is as simple as adding one extra flag: - -```bash -ibmcloud ce app create \ ---name linuxserver-wps-office \ ---port 3000 \ ---image lscr.io/linuxserver/wps-office:latest \ ---env CUSTOM_USER="User" \ ---env PASSWORD="mypwd" \ ---mount-data-store=/mydata=my-cos-pds -``` - -The `--mount-data-store=/mydata=my-cos-pds` flag mounts your COS persistent data store (PDS) to the /mydata directory inside the container, allowing **WPS Office** to read and write files directly to cloud storage. - -Using the **UI**, the process is just as straightforward. When deploying an app like **LibreOffice**, simply specify the persistent data store under the **Volume Mounts** section in addition to the previously specified configuration. This enables your application to retain documents, configurations, or media files between sessions — perfect for collaborative environments or long-term projects. - -![Code Engine PDS](ce-pds.jpg) -![Code Engine App create with Volume mount](ce-volume-mount.jpg) - -## Wrapping Up: What’s Next? - -You’ve now successfully deployed a variety of LinuxServer.io container images on IBM Cloud Code Engine — all following a simple, standardized process. The only things that typically change are the **application name** and the **container image** you choose; everything else remains consistent, making it easy to replicate and deploy new applications. - -As you explore more applications, consider experimenting with different **CPU and memory configurations** to optimize performance based on your specific use case. Code Engine also offers advanced features like custom **domain mappings**, which can help you make your applications more accessible and professional. For added security and flexibility, you can dive into **advanced container configurations**, or integrate more sophisticated **authentication methods** to protect your services. - -## Final Thoughts - -IBM Cloud Code Engine and LinuxServer.io together provide a powerful, intuitive way to run open-source applications in the cloud. Whether you’re a developer building scalable services, an educator setting up browser-based labs, or a hobbyist exploring creative tools — this combination makes cloud-native computing accessible to everyone. - -**Ready to get started?** - -Explore the LinuxServer.io catalog, pick your favorite app, and deploy it with just a few clicks or a single command directly to [IBM Cloud Code Engine](https://www.ibm.com/products/code-engine). The cloud is yours to build with — simple, secure, and serverless. \ No newline at end of file diff --git a/content/posts/Writing-typescript-functions-for-ibm-cloud-code-engien/featured.jpg b/content/posts/Writing-typescript-functions-for-ibm-cloud-code-engien/featured.jpg deleted file mode 100644 index aeb1e1844..000000000 Binary files a/content/posts/Writing-typescript-functions-for-ibm-cloud-code-engien/featured.jpg and /dev/null differ diff --git a/content/posts/Writing-typescript-functions-for-ibm-cloud-code-engien/index.md b/content/posts/Writing-typescript-functions-for-ibm-cloud-code-engien/index.md deleted file mode 100644 index df98caf8d..000000000 --- a/content/posts/Writing-typescript-functions-for-ibm-cloud-code-engien/index.md +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: "Writing TypeScript Functions for IBM Cloud Code Engine" -date: 2025-08-04 -description: "Writing TypeScript Functions for IBM Cloud Code Engine" -tags: ["serverless", "code engine", "functions", "typescript"] -featureImage: "featured.jpg" -draft: false -authors: ["lukeroy"] ---- - -[IBM Cloud Code Engine](https://www.ibm.com/products/code-engine) is IBM’s serverless platform that allows developers to run apps, jobs, and functions at scale — without the hassle of managing infrastructure. Among its workload types are functions, which currently support Node.js and Python runtimes. -In this post, we’ll explore how to write a TypeScript function and deploy it as a Node.js function on IBM Cloud Code Engine. This approach lets you enjoy the benefits of TypeScript — like static typing and modern language features — while still running your function as JavaScript. - -TypeScript is a superset of JavaScript that adds optional static typing and other powerful features. It helps catch bugs early and improves code maintainability. However, IBM Cloud Code Engine functions expect JavaScript files, so we need to transpile our TypeScript code to JavaScript before deployment. - -Let’s walk through setting up a simple TypeScript-based function that uses a third-party module. The Code can be found in the following [GitHub Repository](https://github.com/IBM/CodeEngine/tree/main/helloworld-samples/function-typescript-codebundle-nodejs) - -## 1. Create your main function file in TypeScript - -Write your function logic in index.ts. For example, the following function imports the lorem-ipsum module and returns a randomly generated paragraph: - -```javascript -import { LoremIpsum } from "lorem-ipsum"; - -interface Params { - [key: string]: any; -} -interface Response { - headers: { [key: string]: string }; - body: string; -} -export function main(params?: Params): Response { - const lorem = new LoremIpsum(); - return { - headers: { "Content-Type": "text/plain;charset=utf-8" }, - body: lorem.generateWords(10), - }; -} -``` -## 2. Set up your package.json - -Define your dependencies and scripts. Include TypeScript as a devDependency, and use the postinstall script to transpile your TypeScript code to JavaScript automatically after installation: - -```json -{ - "name": "ts-func", - "version": "1.0.0", - "main": "index.js", - "scripts": { - "postinstall": "tsc" - }, - "devDependencies": { - "typescript": "^5.9.2" - }, - "dependencies": { - "lorem-ipsum": "^2.0.8" - } -} -``` - -## 3. Create a tsconfig.json file - -This configuration tells TypeScript how to transpile your code: - -```json -{ - "compilerOptions": { - "module": "nodenext", - "target": "esnext", - } -} -``` - -## 4. Deploy your function to IBM Cloud Code Engine - -After setting up all required files (index.ts, package.json, and tsconfig.json), navigate to your project directory and use the IBM Cloud CLI to create or update your function. Since TypeScript is listed as a devDependency and the tsc command is defined in the postinstall script, IBM Cloud Code Engine will automatically run the TypeScript compiler during its build process — saving you the effort of manually transpiling your code. - -```bash -ibmcloud ce fn create --name ts-func --runtime nodejs-22 --build-source . -``` - -You’ve now successfully created a Node.js function for IBM Cloud Code Engine — while taking full advantage of TypeScript’s type safety and modern features. Give it a try in your next project and experience the benefits of cleaner, more reliable serverless code. \ No newline at end of file diff --git a/content/posts/chennai-region/chennai.jpg b/content/posts/chennai-region/chennai.jpg deleted file mode 100644 index d98346337..000000000 Binary files a/content/posts/chennai-region/chennai.jpg and /dev/null differ diff --git a/content/posts/chennai-region/featured.jpg b/content/posts/chennai-region/featured.jpg deleted file mode 100644 index d98346337..000000000 Binary files a/content/posts/chennai-region/featured.jpg and /dev/null differ diff --git a/content/posts/chennai-region/index.md b/content/posts/chennai-region/index.md deleted file mode 100644 index 194fdff5b..000000000 --- a/content/posts/chennai-region/index.md +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: "IBM Cloud Code Engine Is Now Available in the Chennai Region" -date: 2026-06-18 -description: "Code Engine now available in India." -tags: ["serverless", "code engine", "GPU", "AI", "serverless fleets", "news"] -featureImage: "featured.jpg" -draft: false -authors: ["uwefassnacht"] ---- - -**We're excited to announce that [IBM Cloud Code Engine](https://cloud.ibm.com/codeengine/overview) is now generally available in the Chennai, India (`in-che`) region — expanding our serverless platform deeper into South Asia and giving customers in India a local deployment target for their cloud-native workloads.** - ---- - -## What Is IBM Cloud Code Engine? - -[IBM Cloud Code Engine](https://cloud.ibm.com/codeengine/overview) is a fully managed, serverless platform that lets you run containerized workloads — applications, batch jobs, and event-driven functions — without ever having to think about the underlying infrastructure. IBM deploys, manages, and autoscales your cluster so you can focus entirely on writing code. - -Whether you're deploying a web API, processing data in a batch job, or building an event-driven microservice, Code Engine provides a single, unified deployment experience across all workload types: - -- **Applications** — Deploy HTTP-driven workloads that scale automatically from zero to handle any amount of traffic, then scale back down to zero when idle — so you only pay for what you use. -- **Batch jobs** — Run compute-intensive, time-bounded workloads at scale without managing servers or Kubernetes clusters. -- **Event-driven functions** — Execute lightweight code in response to events from IBM Cloud services, Kafka topics, or custom event sources. -- **Source-to-URL builds** — Point Code Engine at your source code repository and it builds and deploys your container image automatically. - ---- - -## Why Chennai? - -The Chennai region (`in-che`) is hosted on Airtel infrastructure and is part of IBM Cloud's [Single-Campus Multi-Zone Region (SC-MZR)](https://cloud.ibm.com/docs/overview?topic=overview-locations) topology. It spans three independent availability zones — `in-che-1`, `in-che-2`, and `in-che-3` — within a single campus designed with fault-independent power, cooling, networking, and physical security. This gives customers: - -- **Data residency in India** — Keep workloads and data within India to meet compliance and regulatory requirements. -- **Low latency** — Serve end users across South India with significantly reduced network round-trips compared to routing through distant regions. -- **High availability** — The multi-zone architecture protects against zone-level failures automatically, with no manual intervention required. - ---- - -## How to Target the Chennai Region - -Switching to the Chennai region with the [IBM Cloud CLI](https://cloud.ibm.com/docs/cli) takes a single command: - -```bash -ibmcloud target -r in-che -``` - -Once targeted, create a new Code Engine project and deploy your application as you normally would. For full details on all supported regions and API endpoints, see the [Code Engine regions documentation](https://cloud.ibm.com/docs/codeengine?topic=codeengine-regions). - -### Chennai API Endpoints - -| Endpoint type | Address | -|---|---| -| Public API endpoint | `api.in-che.codeengine.cloud.ibm.com` | -| Private API endpoint | `api.private.in-che.codeengine.cloud.ibm.com` | -| Application URL (public) | `..in-che.codeengine.appdomain.cloud` | -| Application URL (private) | `..private.in-che.codeengine.appdomain.cloud` | - ---- - -## Getting Started - -New to Code Engine? The [Getting started guide](https://cloud.ibm.com/docs/codeengine?topic=codeengine-getting-started) walks you through deploying your first "Hello World" application end to end in just a few minutes. You can also explore the [Serverless web application tutorial](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-serverless-webapp) for a more complete example using Code Engine alongside IBM Cloud Object Storage and Cloudant. - ---- - -## Useful Links - -| Resource | Link | -|---|---| -| Code Engine product overview | [cloud.ibm.com/codeengine](https://cloud.ibm.com/codeengine/overview) | -| Documentation home | [cloud.ibm.com/docs/codeengine](https://cloud.ibm.com/docs/codeengine) | -| Getting started guide | [Getting started with Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-getting-started) | -| Supported regions & endpoints | [Code Engine regions](https://cloud.ibm.com/docs/codeengine?topic=codeengine-regions) | -| IBM Cloud global locations | [IBM Cloud region and data center locations](https://cloud.ibm.com/docs/overview?topic=overview-locations) | -| Serverless web app tutorial | [Serverless web application with Code Engine](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-serverless-webapp) | - ---- - -The Chennai expansion is part of IBM's continued investment in the India market and our commitment to bringing enterprise-grade cloud services closer to customers. Ready to deploy? - -**[Try Code Engine in Chennai today →](https://cloud.ibm.com/codeengine/overview)** diff --git a/content/posts/deploy-from-bob/featured.jpg b/content/posts/deploy-from-bob/featured.jpg deleted file mode 100644 index 6d939a875..000000000 Binary files a/content/posts/deploy-from-bob/featured.jpg and /dev/null differ diff --git a/content/posts/deploy-from-bob/index.md b/content/posts/deploy-from-bob/index.md deleted file mode 100644 index e5b99c60e..000000000 --- a/content/posts/deploy-from-bob/index.md +++ /dev/null @@ -1,452 +0,0 @@ ---- -title: "From Laptop to Cloud in Minutes: Deploying with Bob and Code Engine" -date: 2026-07-02 -description: "Using Bob to deploy an app to Code Engine" -tags: ["Bob", "serverless", "code engine", "AI"] -featureImage: "featured.jpg" -draft: false -authors: ["uwefassnacht","jeremiaswerner"] ---- - -What if deploying your application to the cloud was as simple as having a conversation? No memorizing commands, no context-switching to documentation, just you describing what you want and your AI assistant making it happen. - -That's exactly what happens when you combine [IBM Cloud Code Engine](https://www.ibm.com/cloud/code-engine) with [Bob](https://www.ibm.com/products/watsonx-code-assistant), your AI-powered deployment partner. Code Engine already makes serverless deployment straightforward, but Bob takes it to the next level by turning deployment into a natural conversation. - -In this tutorial, you'll learn how to deploy a simple static website to Code Engine using Bob—from generating the code to seeing it live in the cloud. Let's get started! - -## What You'll Build - -By the end of this tutorial, you'll have: -- ✅ Bob's Code Engine Specialist skill installed -- ✅ A simple "Hello World" static website (generated by Bob) -- ✅ Your site deployed and running on IBM Cloud Code Engine -- ✅ A live URL you can share with anyone - -**Time to complete**: 15-20 minutes - -## Prerequisites - -Before we begin, make sure you have: - -1. **An IBM Cloud account** - [Sign up for free](https://cloud.ibm.com/registration) if you don't have one -2. **Bob 2.0 (or higher) installed** - Your AI coding assistant ([Learn more about Bob](https://www.ibm.com/products/watsonx-code-assistant)) -3. **IBM Cloud CLI** - [Installation guide](https://cloud.ibm.com/docs/cli?topic=cli-install-ibmcloud-cli) -4. **Code Engine CLI plugin** - Install with: `ibmcloud plugin install code-engine` - -Don't worry if you're new to Code Engine—Bob will guide you through everything! - -## Step 1: Install the Code Engine Skill for Bob - -Bob's Code Engine expertise comes from a dedicated skill that you install once. This skill gives Bob deep knowledge of IBM Cloud Code Engine deployments, configurations, and troubleshooting. - -### 1.1 Open Bob in an existing or new folder - -Open Bob in your development environment (VS Code, terminal, or wherever you have Bob configured). Either open an existing project folder or create a new one for Bob to work in. - -### 1.2 Install the Code Engine Skill - -In Bob, type the following command: - -```text -Install the code-engine-specialist skill in this workspace using the following command: - -npx skills add github:IBM/CodeEngine --skill code-engine-specialist -y 2>&1 || true -``` - -Bob will: -- Fetch the official IBM Code Engine skill directly from GitHub -- Install it in your workspace so it's available in your projects -- Make the skill immediately available — no restart required - -> Note: If you want to install the skill globally, make sure you have enabled **Allow outside workspace tools** (In the IBM Bob chat -> Settings (icon) -> Chat -> Allow outside workspace tool requests) - - -### 1.3 Verify the Skill is Active - -Once installed, confirm the skill is available by asking Bob: - -```text -Do you have the code-engine-specialist skill installed? -``` - -Bob will confirm the skill is active and ready to use. - -## Step 2: Authenticate with IBM Cloud - -Before deploying anything, you need to authenticate with IBM Cloud. - -### 2.1 Log in to IBM Cloud - -Open your terminal and run: - -```bash -ibmcloud login --sso -``` - -Or if you have an API key: - -```bash -ibmcloud login --apikey YOUR_API_KEY -``` - -Follow the prompts to complete authentication. - -### 2.2 Target a Resource Group - -IBM Cloud organises resources into resource groups. Every IBM Cloud account comes with a **Default** resource group, so that's a safe choice if you haven't created any others. - -Run the following command to target it: - -```bash -ibmcloud target -g Default -``` - -You should see output similar to: - -``` -Targeted resource group Default -``` - -> **Tip:** If your account uses a different resource group, replace `Default` with its name. You can list all available resource groups with `ibmcloud resource groups`. - -### 2.3 Verify Authentication with Bob - -Now let's have Bob verify your authentication. Tell Bob: - -```text -Check my IBM Cloud authentication -``` - -Bob will run the verification and show you something like: - -```text -🔐 Authentication Status Check ---- -✅ Authenticated as: your-email@example.com - Account: Your IBM Cloud Account - Region: us-south - Resource Group: Default - -Ready to proceed with Code Engine deployment! -``` - -If you see any errors, Bob will guide you through fixing them. - -## Step 3: Generate a Hello World Website - -Now for the fun part—let's have Bob create a simple static website for us! - -### 3.1 Ask Bob to Create the Website - -Tell Bob: - -```text -Create a simple hello world static website with HTML, CSS, and JavaScript -``` - -### 3.2 Review What Bob Creates - -Bob will generate three files: - -- **`index.html`** — the page structure, with a heading, a short description, and an interactive button -- **`styles.css`** — styling that centres the content on the page and gives the button a hover effect -- **`script.js`** — a small click handler that displays a random fun message when the button is pressed - -### 3.3 Test Locally (Optional) - -You can test the website locally by opening `index.html` in your browser. The button should display random messages when clicked. - -> **No Dockerfile needed**: When you ask Bob to deploy, it will automatically detect that this is a static website and create the appropriate Dockerfile — using nginx on port 8080 — before building and deploying the container. - -## Step 4: Deploy to Code Engine with Bob - -Now comes the exciting part—deploying to the cloud! - -### 4.1 Start the Deployment - -Make sure you're in the directory with your website files, then tell Bob: - -```text -Deploy this website to Code Engine -``` - -### 4.2 Follow Bob's Guided Workflow - -The deployment is **conversational** — Bob will ask you a series of questions to configure the deployment correctly. The exact wording of Bob's responses will vary, but expect Bob to: - -1. **Verify your IBM Cloud authentication** and confirm the active region -2. **Analyse your files** — detecting that this is a static website and auto-generating a Dockerfile (nginx on port 8080) since you don't have one -3. **Ask for a name** for your application (e.g. `hello-world-site`) -4. **Ask about expected traffic** — choose *Low* for a demo site so it scales to zero when idle -5. **Confirm resource settings** — Bob will suggest sensible CPU and memory defaults for a static site - -Answer each question as it comes. Bob handles the rest. - -> **Note:** Bob's output is generated dynamically — the exact phrasing, formatting, and follow-up questions you see may differ from what's shown here. That's normal; just follow the conversation. - -### 4.3 Watch the Deployment and Visit Your Site - -Once you've answered Bob's questions, it will build the container, push it to IBM Container Registry, and deploy it to Code Engine — reporting progress as it goes. When finished, Bob will give you a live URL. - -> **Note:** Some steps (e.g. project creation or application deployment) might take a minute or two ... be patient and follow the conversation - -Open that URL in your browser to see your Hello World site up and running. - -### 4.4 View Application Details in IBM Cloud (Optional) - -If you'd like to explore the full application configuration, logs, and scaling settings in the IBM Cloud UI, ask Bob: - -```text -Give me a link to the code engine application details in the IBM Cloud UI -``` - -Bob will give you a direct link to the application's detail page in the IBM Cloud user interface. - -## Step 5: Understanding What Just Happened - -Let's break down what Bob did for you: - -### 5.1 Behind the Scenes - -Bob executed several Code Engine commands on your behalf: - -1. **Created a Code Engine project** (if you didn't have one) -2. **Built your container image** from the Dockerfile -3. **Pushed the image** to IBM Container Registry -4. **Created a Code Engine application** with your specified configuration -5. **Deployed the container** and configured auto-scaling -6. **Set up health checks** to ensure your app stays healthy -7. **Generated a public URL** for your website - -### 5.2 What You Get with Code Engine - -Your website now has: - -- ✅ **Auto-scaling**: Scales up and down automatically based on traffic -- ✅ **Pay-per-use**: Only pay when your site is being accessed -- ✅ **HTTPS by default**: Secure connection automatically configured -- ✅ **Global availability**: Accessible from anywhere in the world -- ✅ **Automatic health monitoring**: Code Engine restarts if anything fails -- ✅ **Zero infrastructure management**: No servers to maintain - -### 5.3 Cost Efficiency - -Because you chose "Low traffic" with scale-to-zero: -- When no one is visiting: **$0/hour** (scaled to zero) -- When someone visits: Minimal cost for the few seconds of compute time -- Perfect for demos, personal projects, and low-traffic sites - -## Step 6: Making Changes and Redeploying - -Want to update your website? Bob makes it easy! - -### 6.1 Make a Change - -Edit your `index.html` file. For example, change the heading: - -```html -

🚀 Hello World - Version 2!

-``` - -### 6.2 Redeploy with Bob - -Simply tell Bob: - -```text -Redeploy my website to Code Engine -``` - -Bob will: -- Detect the changes -- Rebuild the container -- Deploy the new version -- Verify it's working - -The whole process takes just a few minutes! - -## Step 7: Exploring More with Bob - -Now that you've deployed your first application, try asking Bob: - -### View Your Application Status -```text -Show me the status of my Code Engine application -``` - -### Check the Logs -```text -Show me the logs for hello-world-site -``` - -### Scale Your Application -```text -I am expecting more load. Can you increase the resources and number of instances? -``` - -Bob may suggests different options, pick one and observe how Bob scales the application. - -### Add Environment Variables -```text -Add an environment variable API_KEY to my application -``` - -### Set Up a Custom Domain -```text -How do I configure a custom domain for my Code Engine app? -``` - -Bob will guide you through each of these tasks conversationally! - -### Delete the application - -```text -Delete the application -``` - -## What Makes This Special - -Let's reflect on what you just experienced: - -### It Was Conversational -You didn't need to memorize any `ibmcloud ce` commands. You just described what you wanted, and Bob handled the technical details. - -### It Was Contextual -Bob analyzed your files, understood you had a static website, and configured everything appropriately (nginx, port 8080, resource allocation). - -### It Was Educational -Throughout the process, Bob explained what was happening and why. You learned about Code Engine concepts naturally. - -### It Was Fast -From zero to deployed website in about 15 minutes, including the time to generate the code! - -## Next Steps: Where to Go From Here - -Now that you've deployed your first application with Bob and Code Engine, here are some ideas for what to try next: - -### 1. Deploy a Backend API -Create a Node.js Express API or Python Flask application and deploy it the same way. - -**Try this**: Tell Bob: -```text -Create a simple REST API with Node.js and Express, then deploy it to Code Engine -``` - -### 2. Deploy a Multi-Service Application -Build an application with a frontend and backend, and deploy both to Code Engine. - -### 3. Set Up CI/CD -Configure automatic deployments when you push to GitHub. - -**Ask Bob**: -```text -How do I set up automatic deployments from GitHub to Code Engine? -``` - -### 4. Explore Batch Jobs -Code Engine isn't just for web applications—it can run batch jobs too! - -**Ask Bob**: -```text -Show me how to run a batch job on Code Engine -``` - -### 5. Configure Event-Driven Workloads -Set up your application to respond to events from Cloud Object Storage, Kafka, or cron schedules. - -## Additional Resources - -### Learn More About Code Engine -- [Code Engine Documentation](https://cloud.ibm.com/docs/codeengine) - Complete guide to all features -- [Code Engine Samples](https://github.com/IBM/CodeEngine) - Example applications and tutorials -- [Code Engine Pricing](https://www.ibm.com/cloud/code-engine/pricing) - Understand the cost model -- [Code Engine Free Tier](https://cloud.ibm.com/docs/codeengine?topic=codeengine-pricing#free-tier) - What's included for free - -### Learn More About Bob -- [Bob Documentation](https://www.ibm.com/products/watsonx-code-assistant) - Full capabilities and features -- [Bob Custom Modes](https://www.ibm.com/docs/bob/custom-modes) - Create your own specialized modes -- Bob Community - Connect with other developers using Bob - -### Helpful Tutorials -- [Deploying Containerized Applications](https://cloud.ibm.com/docs/codeengine?topic=codeengine-deploy-app-tutorial) -- [Building from Source Code](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-source) -- [Configuring Auto-scaling](https://cloud.ibm.com/docs/codeengine?topic=codeengine-app-scale) -- [Working with Secrets and ConfigMaps](https://cloud.ibm.com/docs/codeengine?topic=codeengine-configmap-secret) - -## Troubleshooting Tips - -If you run into issues, Bob is there to help! Here are some common scenarios: - -### "My deployment failed" -Ask Bob: -```text -Why did my deployment fail? Can you help me troubleshoot? -``` - -Bob will analyze the error logs and suggest solutions. - -### "My website is slow to load" -Ask Bob: -```text -My website seems slow after being idle. How can I fix this? -``` - -Bob will explain cold starts and help you configure min-scale if needed. - -### "I want to see what's happening" -Ask Bob: -```text -Show me the logs for my application -``` - -Bob will fetch and display the logs, helping you understand what's happening. - -### "I need to change the configuration" -Ask Bob: -```text -I want to increase the memory for my application to 1G -``` - -Bob will update the configuration and redeploy for you. - -## Conclusion: Deployment Made Simple - -You've just experienced the future of cloud deployment. What traditionally required: -- Learning complex CLI commands -- Reading extensive documentation -- Trial and error with configurations -- Manual troubleshooting - -...now happens through a simple conversation with Bob. - -IBM Cloud Code Engine provides the powerful, serverless platform that scales automatically and charges only for what you use. Bob adds the conversational intelligence that makes it feel effortless. Together, they create a deployment experience where you focus on building great applications, and the cloud infrastructure just works. - -## 🚀 Your Turn! - -Ready to deploy your own application? Here's your action plan: - -### Step 1: Set Up (5 minutes) -- [ ] Ensure you have an IBM Cloud account -- [ ] Install IBM Cloud CLI and Code Engine plugin -- [ ] Install Bob's Code Engine Expert mode - -### Step 2: Deploy (10 minutes) -- [ ] Create or choose an application to deploy -- [ ] Tell Bob: "Deploy this to Code Engine" -- [ ] Follow Bob's guided workflow -- [ ] Celebrate when you see your live URL! 🎉 - -### Step 3: Explore (Ongoing) -- [ ] Try deploying different types of applications -- [ ] Experiment with scaling configurations -- [ ] Ask Bob questions as you learn -- [ ] Share your deployed applications! - ---- - -**Remember**: Deployment doesn't have to be complicated. With Bob and Code Engine, it's as simple as describing what you want. - -Your next deployment is just a conversation away. Happy deploying! 🚀 - ---- - -*Have questions or want to share what you built? Connect with the Bob and Code Engine communities—we'd love to hear about your experience!* diff --git a/content/posts/dynamic-fleets-availability/featured.png b/content/posts/dynamic-fleets-availability/featured.png deleted file mode 100644 index e7297509d..000000000 Binary files a/content/posts/dynamic-fleets-availability/featured.png and /dev/null differ diff --git a/content/posts/dynamic-fleets-availability/fleet-pattern-continuous.svg b/content/posts/dynamic-fleets-availability/fleet-pattern-continuous.svg deleted file mode 100644 index 492005536..000000000 --- a/content/posts/dynamic-fleets-availability/fleet-pattern-continuous.svg +++ /dev/null @@ -1,133 +0,0 @@ - - - - - - - - - - - - - - - 0 - 5 - 8 - 10 - 12 - - - - max=12 - - - - min=5 - - - - - - - - - - - - - +5 tasks - → 8 slots - - - +5 tasks - → 12 slots - - - 5 done - → 10 (delay) - - - delay exp. - → 8 slots - - - 5 done - → min (5) - - - - - - scale_down_delay - - - - Running tasks - - Free slots - - Total slots provisioned - - scale_min floor - - scale_max ceiling - - - - Time → - - - Container slots - diff --git a/content/posts/dynamic-fleets-availability/fleet-pattern-oneshot.svg b/content/posts/dynamic-fleets-availability/fleet-pattern-oneshot.svg deleted file mode 100644 index aca8fa902..000000000 --- a/content/posts/dynamic-fleets-availability/fleet-pattern-oneshot.svg +++ /dev/null @@ -1,41 +0,0 @@ - - - - - - - - - - - - 0 - max - - - - - - - - fleet complete · 0 workers - - - Container slots running at scale_max - - - - Create fleet - with all tasks - - - Last task done - → scale to zero - - - - Time → - - - Container slots - diff --git a/content/posts/dynamic-fleets-availability/fleet-pattern-scheduled.svg b/content/posts/dynamic-fleets-availability/fleet-pattern-scheduled.svg deleted file mode 100644 index 80839c5d3..000000000 --- a/content/posts/dynamic-fleets-availability/fleet-pattern-scheduled.svg +++ /dev/null @@ -1,91 +0,0 @@ - - - - - - - - - - - - - - 0 - max - - - - - - - - - - - - - - - - - - - - - - - - - - - - Mon - Tue - Wed - Thu - Fri - - - - - - - - - - ← same fleet, lives indefinitely → - - - - - - - - - - - - add_tasks - add_tasks - add_tasks - add_tasks - add_tasks - - 06:00 - 06:00 - 06:00 - 06:00 - 06:00 - - - Container slots - diff --git a/content/posts/dynamic-fleets-availability/index.md b/content/posts/dynamic-fleets-availability/index.md deleted file mode 100644 index d86dfea0b..000000000 --- a/content/posts/dynamic-fleets-availability/index.md +++ /dev/null @@ -1,162 +0,0 @@ ---- -title: "IBM Cloud Code Engine Fleets Just Got More Flexible: Keep Fleets Alive and Submit Tasks Anytime" -date: 2026-09-04 -description: "IBM Cloud Code Engine Serverless Fleets are getting more powerful. Create a fleet once, tune it for your latency requirements, then submit tasks to it over time. Eliminated are repetitive configurations, and infrastructure overhead." -tags: ["serverless", "code engine", "serverless fleets", "scaling", "batch", "news"] -featureImage: "featured.png" -draft: false -authors: ["saschaschwarze"] ---- - -**IBM Cloud Code Engine Serverless Fleets are getting more powerful. Create a fleet once, tune it for your latency requirements, then submit tasks to it over time. Eliminated are repetitive configurations, and infrastructure overhead.** - -## What Is IBM Cloud Code Engine? - -[IBM Cloud Code Engine](https://www.ibm.com/products/code-engine) is IBM's fully managed, serverless platform that lets you run containerized workloads — applications, batch jobs, event-driven functions, and large-scale parallel task fleets — without ever thinking about the underlying infrastructure. IBM handles provisioning, scaling, networking, and security so you can focus entirely on your code. - -[Serverless Fleets](https://cloud.ibm.com/docs/codeengine?topic=codeengine-cefleets) are Code Engine's answer to massively parallel, run-to-completion workloads. They execute tasks across a pool of dedicated Virtual Server Instances (VSIs) inside your own Virtual Private Cloud (VPC), giving you single-tenant isolation, full control over subnets, and access to a wide range of instance flavors — including GPU-enabled ones. - -## How Fleets Worked Until Now - -When you created a fleet, you supplied everything in one go: the container image, network placement, container resources, environment variables, mounted data stores, the task state store — and the full set of tasks to run. The fleet would spin up workers, process every task, and shut down — ending in a **succeeded** status if all tasks completed successfully, or **failed** if any task encountered an error. - -That model works well for a fixed workload, but it has a real limitation: **tasks are a one-time input**. If you needed to process another batch of work — even with the exact same image and infrastructure — you had to create a brand-new fleet and specify all of those details again. There was no way to hand more work to a fleet that was already configured and running. - -## What's New: Create Once, Add Tasks Anytime - -Today that changes. You can now **add tasks to an existing fleet at any time**. - -You configure your fleet's infrastructure exactly once — image, network placement, resources, environment variables, secrets, data store mounts — and then any part of your system can submit new work with a single lightweight call that contains nothing but the task specification itself. No image reference. No network config. No resource declaration. The fleet already knows all of that. - -Because a fleet can always receive more work, it no longer terminates with a succeeded or failed status when its tasks finish. Instead, once all tasks completed, the fleet transitions to **standby** status — workers scale down, infrastructure stays configured, and the fleet waits ready for the next batch. It only reaches a terminal status if you explicitly cancel it. - -All fleet operations — creating a fleet, adding tasks, and monitoring progress — are available through the **Code Engine UI**, the **`ibmcloud` CLI**, and the **REST API**. - -Alongside the ability to add tasks, a set of scaling parameters give you precise control over how the fleet provisions and retains workers: - -- **`scale_max_instances`** _(existing)_ — the upper bound on total container slots. The fleet never provisions more workers than needed to fill this many slots in parallel. -- **`scale_min_instances`** _(new)_ — the minimum number of container slots kept provisioned at all times, even when no tasks are pending. The fleet never scales below this floor, so there are always workers ready to pick up incoming tasks without a cold start. -- **`scale_spare_instances`** _(new)_ — the number of free slots maintained above whatever is currently running. When a task arrives and spare slots are available, it starts within seconds. The fleet provisions additional workers in the background to restore the spare buffer. -- **`scale_down_delay`** _(new)_ — how long a worker stays alive after completing its last task before becoming eligible for scale-down. This prevents the fleet from aggressively deprovisioning workers during short gaps between bursts of work. - -Together these parameters let you tune a fleet from fully on-demand (default values) to always-warm with instant response, depending on your latency requirements like in the following three patterns. - -## The Three Fleet Patterns - -The new capabilities enable the usage of fleets for more scenarios that one can devide into three common patterns. - -### Pattern 1 — One-Shot Batch _(existing)_ - -You know all tasks up front, supply them at fleet creation, and the fleet runs to completion. Workers scale up, burn through every task, and scale back to zero automatically. - -**The only scaling parameter you need:** `scale_max_instances` - -**Best for:** One-time data migrations, bulk re-encoding a media archive, generating a report from a fixed dataset — any workload where you know all the work up front and just want it done. - -![One-shot batch fleet lifecycle: workers scale up at creation, run at scale_max, then drop to zero when the last task completes.](fleet-pattern-oneshot.svg) - -### Pattern 2 — Scheduled Batch Additions _(new)_ - -One fleet lives indefinitely. On a predictable schedule — say, every morning — you call the `add_tasks` endpoint to inject the next batch of work. The fleet wakes up, processes everything, and scales back to zero until tomorrow. No need to create a new fleet each cycle. The fleet accumulates task history. Providing a `batch_name` when adding tasks gives you clear traceability per run. - -Because the fleet is created once and reused, all the details you only want to specify once — the VPC network placement, the task state store, the container image, environment variables, mounted data stores, and resource sizes — are configured at creation and stay in place forever. Each scheduled `add_tasks` call only carries the new work; nothing else changes. - -**The only scaling parameter you need:** `scale_max_instances` - -**Best for:** Daily transaction processing, overnight report generation, partner file ingestion from COS. - -![Scheduled batch fleet lifecycle: the same fleet receives add_tasks calls on a schedule, processes each batch, then idles at zero workers between runs.](fleet-pattern-scheduled.svg) - -Each morning, a scheduled Code Engine job adds the new batch of tasks — identified by a `batch_name` for traceability — while the fleet itself requires no changes between runs. - -### Pattern 3 — Continuous, Latency-Sensitive Workload _(new)_ - -Tasks arrive at any time, triggered by user actions, sensor events, or real-time data streams. Cold-starting a new worker for every incoming task would add seconds of latency you can't afford. The new scaling parameters let you maintain a **pool of warm, ready workers** at all times. - -Like the scheduled pattern, this fleet is created once. Your infrastructure team sets it up with the right VPC subnet, instance size, GPU type, container image, and secrets — and then any caller anywhere in your system can submit tasks by calling `add_tasks` with nothing more than the task specification. The fleet configuration never has to be in application code that submits the tasks. - -**Relevant scaling parameters:** `scale_max_instances`, `scale_min_instances`, `scale_spare_instances`, `scale_down_delay` - -**Best for:** Fraud detection, real-time inference, interactive rendering, any latency-sensitive workload. - -The diagram below uses the following example configuration to illustrate the scaling behaviour: - -- **`scale_min_instances = 5`** — the fleet always keeps at least 5 container slots provisioned, even when no tasks are running (the amber dashed line). At rest, total provisioned = **5**. -- **`scale_spare_instances = 3`** — once tasks are running, 3 additional free slots are maintained above the running count so new tasks can start instantly. At rest there are no running tasks, so no spare is added yet. -- **`scale_max_instances = 12`** — the hard ceiling on total provisioned slots (the red dashed line). This limit becomes relevant when 10 tasks are running: the fleet would want 10 + 3 spare = 13, but is capped at 12, leaving only 2 free slots. -- **`scale_down_delay = 10m`** — after a task completes, the slot stays warm for 10 minutes before scaling down. - -With these values the example plays out as follows: - -1. **At rest** — 5 slots provisioned (= min), 0 tasks running. -2. **+5 tasks added** — all 5 start immediately on the existing min slots. Fleet adds 3 spare on top → **8 slots total**. -3. **+5 more tasks added** — 3 start immediately on the spare slots; the other 2 are briefly pending while the fleet scales up. Fleet wants 13 but is capped at `scale_max` → **12 slots total** (10 running + 2 free). -4. **First 5 tasks complete** — 5 tasks still running. `scale_down_delay` keeps the freed slots warm → **10 slots total**. -5. **Delay expires** — fleet scales down to running (5) + spare (3) → **8 slots total**. -6. **Remaining 5 tasks complete** — fleet scales back to min → **5 slots total**. - -![Continuous fleet lifecycle: spare capacity absorbs task bursts instantly, scale_down_delay keeps workers warm after completion, and scale_min maintains a permanent floor.](fleet-pattern-continuous.svg) - -Notice how the first batch of tasks starts without any cold-start wait — the existing min slots are ready. When the second batch arrives, 3 tasks start right away on the spare slots; the remaining 2 start shortly after as the fleet scales up to restore spare capacity. - -## Try It: An End-to-End CLI Walkthrough - -Here is a complete example using the `ibmcloud` CLI that shows the fleet creation and addition of tasks from start to finish. The fleet is created once — with all infrastructure details locked in — and tasks are added on each daily run without touching the fleet definition again. - -### Step 0: Set up the environment (one time only) - -Before creating a fleet you need a few IBM Cloud resources in place: a VPC with a subnet, a Code Engine project, and a COS bucket for the task state store and input data. If you don't have these yet, the [one-time setup script](https://github.com/IBM/CodeEngine/tree/main/serverless-fleets#one-time-setup) in the IBM/CodeEngine repository walks through creating everything from scratch using the `ibmcloud` CLI. - -If you previously installed the IBM Cloud CLI already, make sure to update the Code Engine plugin to the latest version to have the new features available: `ibmcloud plugin update code-engine` - -### Step 1: Create the fleet (one time only) - -Create the fleet with its image, network placement, data store mounts, and scaling configuration. No tasks are provided yet. - -```bash -ibmcloud code-engine fleet create \ - --name transaction-processor \ - --image icr.io/codeengine/helloworld \ - --subnetpool-name fleet-subnetpool \ - --tasks-state-store fleet-task-store \ - --cpu 1 \ - --memory 4G \ - --scale-max 20 \ - --env SLEEP=10 -``` - -This is the only time you specify the image, VPC placement, resource sizes, and environment variables. From here on, every `fleet task add` call is just a few lines. - -### Step 2: Add the first tasks - -With a single command, you add tasks to the fleet. The `--fleet-id` targets the existing fleet that you capture from step(1); everything else is just the batch specification. - -```bash -ibmcloud code-engine fleet task add \ - --fleet-id \ - --batch-name 2026-09-03-transactions \ - --tasks 100 -``` - -Code Engine picks up the new tasks, spins up workers against the already-configured fleet, and scales back to zero once the batch is done. - -In a real-world scenario you will probably not run it with `--tasks 100` but with `--tasks-from-local-file` or `--tasks-from-cos-bucket` to provide the relevant input data of your tasks instead of just some indices. - -### Step 3: Add another batch whenever work arrives - -The same command works at any time — even while the fleet is still processing a previous batch. Tasks from multiple batches can run concurrently up to `scale-max`. - -```bash -ibmcloud code-engine fleet task add \ - --fleet-id \ - --batch-name 2026-09-04-transactions \ - --tasks 100 -``` - -Note that we here used different batch names. However uniqueness is not required. You can as well use the same batch for multiple task additions - for example when you retry failed tasks from a previous batch, or when you group tasks in a way where the reuse makes sense. An example could be that you group transactions by your partners and use the partner name as batch name. - -## Getting Started - -Fleets are available today in all [IBM Cloud Code Engine](https://www.ibm.com/products/code-engine) regions. Check out the [Serverless Fleets documentation](https://cloud.ibm.com/docs/codeengine?topic=codeengine-cefleets) to get started, or explore the ready-to-run samples in the [IBM/CodeEngine GitHub repository](https://github.com/IBM/CodeEngine/tree/main/serverless-fleets). - -Whether you're processing daily transaction files, running real-time fraud checks, or orchestrating GPU-accelerated AI inference — Code Engine Serverless Fleets now have a pattern for every workload shape. diff --git a/content/posts/how-to-blog/featured.jpg b/content/posts/how-to-blog/featured.jpg deleted file mode 100644 index 817de827b..000000000 Binary files a/content/posts/how-to-blog/featured.jpg and /dev/null differ diff --git a/content/posts/how-to-blog/index.md b/content/posts/how-to-blog/index.md deleted file mode 100644 index ea8570b7f..000000000 --- a/content/posts/how-to-blog/index.md +++ /dev/null @@ -1,109 +0,0 @@ ---- -title: "How to post on the Code Engine Dev Blog" -date: 2026-05-27 -description: "A comprehensive guide for authors contributing to the IBM Code Engine blog using Hugo and the Blowfish theme." -tags: ["meta", "guide", "documentation", "hugo"] -featureImage: "featured.jpg" -authors: ["uwefassnacht"] -draft: false ---- - -Welcome to the **IBM Code Engine Developer Blog** contribution guide! This site is powered by Hugo and built using the highly customizable Blowfish Theme. - -To maintain a consistent reading experience, please follow this step-by-step workflow to configure your author bio, format your posts, and submit content. - ---- - -## 1. Setting Up Your Author Profile - -Before writing your first post, you must create an author profile. This generates a rich bio card at the bottom of your articles and populates the global author index pages. - -1. **Create Your Author Directory:** Navigate to `content/authors/` in the repository. Create a new directory named exactly after your author handle (use lowercase and hyphens, e.g., `content/authors/john-doe/`). -2. **Create the Profile Configuration:** Inside your new folder, create an `_index.md` file. This file holds your profile metadata and biography. -3. **Add Your Profile Image:** Place an avatar image (JPG or PNG, ideally square) into your author folder. Name it `avatar.jpg` or `avatar.png`. Blowfish will detect and render it automatically. - -### Author Template -Copy and paste this structure into your `content/authors//_index.md` file: - -````toml ---- -title: "John Doe" -searchHidden: true # Keeps your profile page out of general article searches -# Social Media Links -links: - - github: "https://github.com/your-username" - - linkedin: "https://linkedin.com/in/your-profile" - - twitter: "https://twitter.com/your-handle" ---- - -Write a short, engaging 2-3 sentence biography here. Explain your role at IBM, your technical focus areas (like Cloud Native Serverless systems, Kubernetes, or Knative), and what you enjoy working on outside of coding. -```` - ---- - -## 2. Creating a New Post - -All articles are written in standard Markdown and live inside the `content/posts/` directory. - -### Step 1: Create the File -Create a new file named `your-post-title.md` inside `content/posts/`. - -### Step 2: Configure Front Matter -Every article requires a block of configuration at the absolute top of the file, wrapped in triple hyphens (`---`). Use this exact template: - -```yaml ---- -title: "Deploying Microservices with Code Engine" -date: 2026-05-27 -description: "A deep dive into deploying containerized applications with minimal infrastructure configuration." -tags: ["code-engine", "serverless", "containers"] -categories: ["tutorials"] -author: "john-doe" # Must exactly match your folder name in content/authors/ -showTaxonomies: true -showAuthor: true -showAuthorBottom: true ---- -```` - -> **Crucial Rule:** Ensure the `author` string matches your author profile directory name exactly. If it doesn't, your bio card won't load and global author filtering will fail. - ---- - -## 3. Formatting and Styling Content - -Blowfish includes rich utility components to make your content visually engaging. Make sure to review the Official Blowfish Content Structure Guide ([https://blowfish.page/docs/content/](https://blowfish.page/docs/content/)) for comprehensive examples. - -### Code Snippets and Syntax Highlighting -Always specify the programming language next to your opening backticks to enable clean code block rendering: - -```javascript -// Example of clean syntax highlighting -const client = new CodeEngineClient(); -await client.deployApplication("my-app"); -``` - -### Shortcodes and Alerts -Blowfish provides elegant custom components called "shortcodes" to call out critical details or warnings. - -* **Alert Boxes:** Use these to emphasize specific configurations or caveats. Read more in the Blowfish Alert Shortcode Docs ([https://blowfish.page/docs/shortcodes/#alert](https://blowfish.page/docs/shortcodes/#alert)). - - - {{< alert >}} - **Note:** Code Engine projects automatically scale to zero instances when idle to save resource costs. - {{< /alert >}} - -* **Badges:** Highlight small snippets of inline metadata using the Blowfish Badge Documentation ([https://blowfish.page/docs/shortcodes/#badge](https://blowfish.page/docs/shortcodes/#badge)). - ---- - -## 4. Submission Checklist - -Before opening a Pull Request (PR) on GitHub, ensure you check off the following items: - -* [ ] My author profile exists under `content/authors/` and contains an `_index.md`. -* [ ] The `theme` variable is **not** present in `hugo.toml` (all module imports are handled natively by Go Modules). -* [ ] All tags and categories are lowercase string arrays (e.g., `tags: ["cloud", "devops"]`). -* [ ] I have verified all custom text comparison layouts use clean string descriptors instead of naked `<` or `>` characters to avoid parsing errors. -* [ ] All referenced images are placed contextually or within assets, avoiding broken links. - -For advanced stylistic tweaks, layout adjustments, or multi-language configurations, consult the complete Blowfish Theme Documentation Hub ([https://blowfish.page/docs/](https://blowfish.page/docs/)). diff --git a/content/posts/remote-bob-run-bob-shell-in-the-cloud/01-status.jpg b/content/posts/remote-bob-run-bob-shell-in-the-cloud/01-status.jpg deleted file mode 100644 index 23842433e..000000000 Binary files a/content/posts/remote-bob-run-bob-shell-in-the-cloud/01-status.jpg and /dev/null differ diff --git a/content/posts/remote-bob-run-bob-shell-in-the-cloud/02-setup.jpg b/content/posts/remote-bob-run-bob-shell-in-the-cloud/02-setup.jpg deleted file mode 100644 index 413a7b5e8..000000000 Binary files a/content/posts/remote-bob-run-bob-shell-in-the-cloud/02-setup.jpg and /dev/null differ diff --git a/content/posts/remote-bob-run-bob-shell-in-the-cloud/03-new-session.jpg b/content/posts/remote-bob-run-bob-shell-in-the-cloud/03-new-session.jpg deleted file mode 100644 index c3bec6e8b..000000000 Binary files a/content/posts/remote-bob-run-bob-shell-in-the-cloud/03-new-session.jpg and /dev/null differ diff --git a/content/posts/remote-bob-run-bob-shell-in-the-cloud/04-browser-login.jpg b/content/posts/remote-bob-run-bob-shell-in-the-cloud/04-browser-login.jpg deleted file mode 100644 index 87edc9ea6..000000000 Binary files a/content/posts/remote-bob-run-bob-shell-in-the-cloud/04-browser-login.jpg and /dev/null differ diff --git a/content/posts/remote-bob-run-bob-shell-in-the-cloud/05-bob-shell-welcome.jpg b/content/posts/remote-bob-run-bob-shell-in-the-cloud/05-bob-shell-welcome.jpg deleted file mode 100644 index c4b38d221..000000000 Binary files a/content/posts/remote-bob-run-bob-shell-in-the-cloud/05-bob-shell-welcome.jpg and /dev/null differ diff --git a/content/posts/remote-bob-run-bob-shell-in-the-cloud/06-bob-shell-capabilities.jpg b/content/posts/remote-bob-run-bob-shell-in-the-cloud/06-bob-shell-capabilities.jpg deleted file mode 100644 index adc1a7df6..000000000 Binary files a/content/posts/remote-bob-run-bob-shell-in-the-cloud/06-bob-shell-capabilities.jpg and /dev/null differ diff --git a/content/posts/remote-bob-run-bob-shell-in-the-cloud/07-connect.jpg b/content/posts/remote-bob-run-bob-shell-in-the-cloud/07-connect.jpg deleted file mode 100644 index 74042480d..000000000 Binary files a/content/posts/remote-bob-run-bob-shell-in-the-cloud/07-connect.jpg and /dev/null differ diff --git a/content/posts/remote-bob-run-bob-shell-in-the-cloud/08-ce-job-running.jpg b/content/posts/remote-bob-run-bob-shell-in-the-cloud/08-ce-job-running.jpg deleted file mode 100644 index 05a1fad73..000000000 Binary files a/content/posts/remote-bob-run-bob-shell-in-the-cloud/08-ce-job-running.jpg and /dev/null differ diff --git a/content/posts/remote-bob-run-bob-shell-in-the-cloud/09-ce-job-runs.jpg b/content/posts/remote-bob-run-bob-shell-in-the-cloud/09-ce-job-runs.jpg deleted file mode 100644 index 53d115552..000000000 Binary files a/content/posts/remote-bob-run-bob-shell-in-the-cloud/09-ce-job-runs.jpg and /dev/null differ diff --git a/content/posts/remote-bob-run-bob-shell-in-the-cloud/featured.jpg b/content/posts/remote-bob-run-bob-shell-in-the-cloud/featured.jpg deleted file mode 100644 index c4b38d221..000000000 Binary files a/content/posts/remote-bob-run-bob-shell-in-the-cloud/featured.jpg and /dev/null differ diff --git a/content/posts/remote-bob-run-bob-shell-in-the-cloud/index.md b/content/posts/remote-bob-run-bob-shell-in-the-cloud/index.md deleted file mode 100644 index 07092807f..000000000 --- a/content/posts/remote-bob-run-bob-shell-in-the-cloud/index.md +++ /dev/null @@ -1,271 +0,0 @@ ---- -title: "Remote Bob: Run Bob Shell in IBM Cloud Code Engine" -date: 2026-09-01 -description: "Spin up a full Bob Shell terminal running autonomously in IBM Cloud Code Engine — sandboxed, persistent, and accessible from any browser in under 20 minutes." -tags: ["Bob", "code engine", "serverless", "AI", "automation"] -featureImage: "featured.jpg" -draft: false -authors: ["lukeroy", "joachimjordan"] ---- - -## Introduction - -[IBM Cloud Code Engine](https://www.ibm.com/products/code-engine) is IBM's fully managed, strategic serverless platform. It lets you run containerised workloads — applications, batch jobs, and functions — without ever touching infrastructure. Code Engine scales to zero when idle, scales out automatically under load, and charges only for the compute you actually consume. It is the platform of choice for teams that want the power of Kubernetes without the operational overhead. - -[Bob](https://bob.ibm.com/) is IBM's AI software engineering assistant. Bob understands your codebase, executes multi-step agentic tasks, runs CLI commands, manages secrets, and integrates with the full IBM Cloud ecosystem through its skill and MCP-server plugin architecture. Bob Shell — the terminal-first interface to Bob — takes this further: it is a full interactive environment where Bob operates as an autonomous agent, capable of writing, running, and iterating on code with no human in the loop for each individual step. - -Together, Code Engine and Bob open up a compelling new pattern: **running Bob Shell as a serverless cloud workload**. This is what Remote Bob is about. - -Remote Bob gives you a **full Bob Shell terminal running in IBM Cloud Code Engine**, accessible from your local browser. One command provisions the infrastructure. A second command starts a session and opens the terminal. Close the browser tab — the session keeps running in the cloud. Reopen it with a single command. When you are done, tear everything down cleanly or simply let it sit at zero cost until you need it again. - -## Why Run Bob in the Cloud? - -Running an AI coding agent locally is fine for interactive work, but several scenarios benefit from — or require — a cloud-hosted agent: - -### Sandboxed Execution - -Bob can write and execute arbitrary code. When working on exploratory or risky tasks — generating and running build scripts, testing untrusted dependencies, bulk-modifying a large codebase — you may want that execution to happen in an isolated environment, not on your laptop. A Code Engine job run is a disposable container: every session starts from a clean image, and when the job ends the container is gone. Nothing persists to your local machine. - -### Autonomous Long-Running Tasks - -Some tasks take hours: large-scale refactors, multi-stage data pipelines, training-data preprocessing, automated code reviews across hundreds of files. Running these on your laptop ties up your machine, drains the battery, and breaks if you close the lid. Code Engine job runs are designed for exactly this pattern — they run to completion in the cloud while you do other things. Remote Bob makes it trivial to attach a terminal to that running job whenever you want to check progress. - -### Remote and Multi-Device Access - -With Remote Bob, your Bob Shell session is not tied to a single machine. Start a session from your workstation in the morning, reconnect from a laptop on the go, and check in from a coffee shop in the afternoon — all connecting to the same live session. The terminal state, tmux layout, and open buffers are all preserved in the cloud-hosted container. - -### High-Performance Compute on Demand - -Bob doesn't just read code — it builds it, tests it, and runs it. Agentic tasks can be surprisingly compute-intensive: compiling a large monorepo, running a full test suite, processing large datasets as part of an automated pipeline, or parallelising tool calls across many files simultaneously. On a laptop, these tasks compete with everything else running on your machine. In a Code Engine job run, Bob gets dedicated resources. - -The job-agent container supports up to **12 vCPUs and 48 GB of memory** per session. Two lines in `.env` are all it takes: - -```bash -DEFAULT_CPU=12 -DEFAULT_MEMORY=48G -``` - -The next `--new-session` picks up the new sizing automatically — no rebuilding, no re-provisioning. Bob gets exactly the headroom it needs for the duration of the session, and the job costs nothing when it is not running. - -### Cost Efficiency - -Because the apiserver scales to zero between sessions and job runs are stopped when not needed, the idle cost is effectively zero. You pay only for active compute time — typically a few cents per hour of actual use. - ---- - -## Prerequisites - -Before you begin, make sure you have the following in place. You will need a Bob subscription (or free trial), an IBM Cloud account with the right permissions, two API keys (one for IBM Cloud, one for Bob Shell), a gateway password you choose yourself, and a handful of CLI tools that the launcher script relies on. Everything else — the Code Engine project, container images, secrets — is created automatically by `./remote-bob --setup`. - -- **Bob subscription** — An active Bob subscription or [free trial](https://bob.ibm.com) is required to obtain a Bob Shell API key -- **IBM Cloud account** — With permission to create Code Engine projects and Container Registry namespaces -- **IBM Cloud API key** — Needs Code Engine Writer + Container Registry Writer roles -- **Bob Shell API key** — From [bob.ibm.com](https://bob.ibm.com) → Settings → API Keys -- **`ibmcloud` CLI** — [Install](https://cloud.ibm.com/docs/cli); the `code-engine` plugin is installed automatically by the launcher -- **`jq`**, **`curl`**, **`openssl`** — `brew install jq` / `apt install jq`; curl and openssl are pre-installed on macOS and most Linux distros -- **Google Chrome** — Auto-detected on macOS and Linux. Chrome is the most widely used browser and is what the launcher opens automatically; the browser client is a standard HTML/WebSocket page and can be opened in any modern browser manually if you prefer a different one - ---- - -## Quickstart - -### Step 1: Clone the repository and configure - -```bash -git clone https://github.com/IBM/CodeEngine -cd CodeEngine/remote-bob - -# Copy the config template and fill in the two API keys and gateway password -cp .env.template .env -``` - -Open `.env` and set the three required values: - -```bash -BOBSHELL_API_KEY=your-bob-shell-api-key # from bob.ibm.com → Settings → API Keys -GATEWAY_PASSWORD=choose-any-password # protects the browser terminal endpoint -IBMCLOUD_API_KEY=your-ibm-cloud-api-key # needs Code Engine Writer + ICR Writer -``` - -That is it. Everything else — region, resource group name, container image tags, CPU and memory — has sensible defaults and the system works out of the box without touching any of them. That said, all of these values are fully configurable: adjust the region, resource sizing, or any other parameter to match your preferences, and the launcher will pick up the changes on the next run. - -### Step 2: Run status to log in and see current state - -```bash -./remote-bob -``` - -Running `./remote-bob` with no arguments logs in to IBM Cloud and prints a status summary. On first run it creates the resource group and Code Engine project, then tells you what to do next. - -![Status output showing IBM Cloud login and initial setup](01-status.jpg) - -### Step 3: Provision infrastructure and build images - -```bash -./remote-bob --setup -``` - -`--setup` is idempotent: it creates the Code Engine project, provisions secrets, builds the apiserver container image and the job-agent container image, and deploys the apiserver as a Code Engine application. The first run takes a few minutes because both images are built from source on Code Engine. Subsequent runs skip steps that are already complete and only rebuild if source code has changed. - -![--setup output: building apiserver and job-agent, deploying application](02-setup.jpg) - -At the end of setup you will see the apiserver URL and a prompt to run `--new-session`. - -### Step 4: Start a session - -```bash -./remote-bob --new-session -``` - -This submits a new Code Engine job run, waits for the agent to connect to the apiserver (typically under 30 seconds), and then opens a Chrome window pointed at the browser client. - -![--new-session output: job submitted, agent ready after 21s, browser opening](03-new-session.jpg) - -### Step 5: Log in and start working - -The browser client is a self-contained HTML page served from `file://` — no web server required. It prompts for your gateway password, then opens a full xterm.js terminal connected over WebSocket to your Bob Shell session running in Code Engine. - -![Browser login screen for the Remote Bob gateway](04-browser-login.jpg) - -Once authenticated, you are in Bob Shell — the same experience you would have locally, but running as an isolated job in the cloud. - -![Bob Shell welcome screen running inside Code Engine](05-bob-shell-welcome.jpg) - -Bob Shell in the cloud has the full set of capabilities: writing and running code in any language, executing CLI commands, managing files, calling external APIs, and working through multi-step agentic tasks autonomously. - -![Bob Shell capabilities — code, architecture, tooling, data, configuration](06-bob-shell-capabilities.jpg) - -### Step 6: Disconnect and reconnect - -Close the browser tab at any time. The Code Engine job run keeps running — the tmux session inside is untouched. - -To reconnect from any machine: - -```bash -./remote-bob --connect -``` - -`--connect` queries IBM Cloud for the live session, constructs the browser client URL, and opens Chrome again. No re-provisioning, no waiting. - -![--connect output: live session found, browser opening](07-connect.jpg) - -### Step 7: View the running job in IBM Cloud - -You can also monitor the session directly from the IBM Cloud console. Navigate to your Code Engine project and open the Jobs section. You will see the job run listed as **Running**. - -![Code Engine console showing the job run in Running state](08-ce-job-running.jpg) - -Only one session can be active at a time — `--new-session` will refuse to start if one is already running. Once you end a session with `--end-session`, you can start a fresh one. The IBM Cloud console keeps a history of all job runs, showing completed sessions alongside the current one. - -![Code Engine console showing multiple job runs — one running, one succeeded](09-ce-job-runs.jpg) - -### Step 8: End the session and clean up - -```bash -# End the current session (stops job runs; infrastructure stays for fast restart) -./remote-bob --end-session - -# Start another session without rebuilding (seconds, not minutes) -./remote-bob --new-session - -# Remove all IBM Cloud resources when finished -./remote-bob --clean -``` - -`--end-session` gracefully disconnects the agent and deletes all job runs. The apiserver application and Code Engine project remain, so the next `--new-session` starts in seconds rather than minutes. - -`--clean` removes everything: job runs, job definition, application, secrets, Code Engine project, and resource group. It is only needed if you want a complete teardown and to remove all IBM Cloud resources entirely. If you simply end the session without cleaning up, the apiserver scales to zero and no job runs are executing — so no costs are generated. You can start a new session at any time with `--new-session` without going through setup again. - ---- - -## How It Works - -``` -Browser (Chrome, file:// page, xterm.js) - │ WebSocket /ws/browser?token=&agent=&service=ttyd - ▼ -Apiserver (Go, IBM Code Engine app, scales to zero) - │ auth: POST /auth/login → 60s WS token - │ POST /auth/runs → per-run agent token (HMAC-signed) - │ relay: opaque frame proxy — text + binary frames preserved verbatim - │ WebSocket /ws/agent (Bearer ) - ▼ -Job-agent (Go, IBM Code Engine job run) - │ dials apiserver on startup, registers services - │ opens upstream ttyd connection per relay request - ▼ -ttyd → tmux → Bob Shell -``` - -**Apiserver** is a thin authenticated relay deployed as a Code Engine application. It maintains an in-memory agent registry, issues short-lived single-use tokens, and proxies WebSocket frames between the browser and the job-agent without inspecting the payload. It scales to zero when no agent is connected — zero idle cost. - -**Job-agent** is a Go binary deployed as a Code Engine job run. On startup it dials the apiserver control WebSocket, registers the `ttyd` service, and handles relay connections by piping raw frames between the apiserver and a local `ttyd` process. It runs `tmux` → Bob Shell inside `ttyd` and provides a health endpoint for the job run lifecycle. Code Engine job runs have a maximum execution time of 24 hours, which is also the maximum lifetime of a Remote Bob session. For workloads that must run beyond that limit, Code Engine's [daemon run mode](https://cloud.ibm.com/docs/codeengine?topic=codeengine-job-daemon) is the path forward. - -**Browser client** is a single self-contained HTML file loaded from `file://`. It authenticates with the gateway password, opens a WebSocket relay connection, and renders the terminal using xterm.js — no server-side rendering, no CDN dependencies. - -**Secrets** are stored in two IBM Code Engine secrets injected as environment variables: -- `remote-bob-gateway` — `GATEWAY_PASSWORD`, `ENCRYPTION_KEY` -- `remote-bob-bobshell` — `BOBSHELL_API_KEY` - ---- - -## Use Cases in Depth - -### Sandboxed Agentic Coding - -Give Bob a task that involves writing and running unknown code — for example, "generate a data cleaning pipeline for this CSV schema and run it." In a cloud job, that code executes in an isolated container with no access to your local filesystem, no persistent state beyond the job lifetime, and no way to interfere with your development environment. When the job ends, the container is gone. - -### Autonomous Long-Running Agents - -Kick off a task that takes hours — a large-scale codebase migration, an exhaustive test suite run, a multi-repository dependency audit — and let it run overnight. You do not need to keep your laptop awake. Check in from any device with `./remote-bob --connect` to see where Bob got to. For compute-heavy workloads, scale the job up to 12 vCPUs and 48 GB of memory by setting `DEFAULT_CPU` and `DEFAULT_MEMORY` in `.env` before starting the session. - -### CI/CD Integration - -The `--new-session` flow is scriptable. You can trigger a Remote Bob session from a GitHub Actions workflow, inject environment variables via `--env-from-secret`, let Bob run a task, and collect results — all without provisioning or managing long-lived infrastructure. - -### Team Shared Agents - -Remote Bob is personal by design — the IBM Cloud account and Bob subscription belong to whoever ran `--setup`, and one session runs at a time. That said, multiple people can `--connect` to the same running session using the gateway password. This makes it straightforward to hand off a long-running task mid-flight, review what Bob is working on in real time, or demonstrate a live agentic workflow to a colleague — without any re-provisioning. - ---- - -## Command Reference - -- **`./remote-bob`** — Log in, print infrastructure + session status, suggest next step -- **`./remote-bob --setup`** — Provision IBM Cloud resources and build container images. Idempotent — safe to re-run after code changes. -- **`./remote-bob --new-session`** — Submit a job run, wait for the agent to connect, open Chrome -- **`./remote-bob --connect`** — Find the live session and reopen Chrome. No re-provisioning. -- **`./remote-bob --end-session`** — Stop all job runs gracefully. Infrastructure remains for a fast restart. -- **`./remote-bob --clean`** — Delete all provisioned IBM Cloud resources - -All commands accept `--config=FILE` to use a config file other than `.env`. - ---- - -## Conclusion - -Remote Bob demonstrates a pattern that becomes increasingly useful as AI agents take on longer and more complex tasks: **decouple the agent runtime from the developer's local machine** and let serverless infrastructure handle the lifecycle. - -IBM Cloud Code Engine is a natural fit for this. Job runs give you isolated, ephemeral containers that start in seconds and cost nothing when idle. The apiserver application scales to zero between sessions. The total infrastructure footprint is minimal, and the total idle cost is zero. - -Two API keys, one gateway password, one command to provision, one command to start — and Bob is running in the cloud. No infrastructure to manage, no servers to maintain, and nothing running idle when you are not using it. That is the promise of Remote Bob, and Code Engine is what makes it possible. - -## Try It — and Make It Your Own - -Get the code from the [CodeEngine sample repository](https://github.com/IBM/CodeEngine), fill in the two API keys and gateway password, and run `--setup`. From there, the system is yours to extend. - -**Add the tools you need.** The job-agent is a standard container. If Bob needs a tool — a specific CLI, a language runtime, a build toolchain — add it to the Dockerfile. The next `--setup` rebuilds the image and every subsequent session has it available. - -**Persist your work across sessions.** By default each session starts from a clean container. If you want Bob to pick up where it left off — keeping a workspace, a git clone, or accumulated context — connect a [Code Engine persistent data store](https://cloud.ibm.com/docs/codeengine?topic=codeengine-persistent-data-store) to the job and mount it into the workspace directory. Files written there survive across sessions. For larger datasets or shared outputs between sessions, Code Engine also integrates natively with IBM Cloud Object Storage — mount a bucket directly into the job container and Bob can read and write files at scale without any additional infrastructure. - -**Run your own MCP server.** Deploy any MCP server as a Code Engine application alongside the apiserver, wire up the URL as an environment variable in the job-agent secret, and Bob will have access to it in every session. Your tools, your APIs, your data sources — all reachable from the cloud agent without exposing anything to the public internet. - -Remote Bob is a starting point. The session lifecycle, the relay architecture, and the launcher script are all open and composable. Take it, adapt it, and build the cloud agent environment that fits your workflow. - -## Resources - -- [IBM Cloud Code Engine](https://www.ibm.com/products/code-engine) -- [Code Engine Documentation](https://cloud.ibm.com/docs/codeengine) -- [Code Engine Sample Repository](https://github.com/IBM/CodeEngine) — Remote Bob source code lives here -- [Bob (watsonx Code Assistant)](https://www.ibm.com/products/watsonx-code-assistant) -- [IBM Cloud CLI](https://cloud.ibm.com/docs/cli) diff --git a/content/posts/serverless-spa-deployment-with-code-engine-functions/index.md b/content/posts/serverless-spa-deployment-with-code-engine-functions/index.md deleted file mode 100644 index 4a6248930..000000000 --- a/content/posts/serverless-spa-deployment-with-code-engine-functions/index.md +++ /dev/null @@ -1,197 +0,0 @@ ---- -title: "The Serverless Way to Auto-Build and Deploy React, Angular, and Any SPA with IBM Cloud Code Engine Functions" -date: 2026-06-08 -description: "Learn how to deploy Single Page Applications (SPAs) to IBM Cloud Code Engine Functions with automatic builds during deployment. No manual build steps, no infrastructure management—just point Code Engine at your source code and deploy." -tags: ["serverless", "code engine", "functions", "spa", "react", "angular", "svelte"] -draft: false -authors: ["lukeroy", "josip-ledic"] ---- - -# The Serverless Way to Auto-Build and Deploy React, Angular, and Any SPA with IBM Cloud Code Engine Functions - -[IBM Cloud Code Engine](https://www.ibm.com/products/code-engine) is IBM's serverless platform that allows developers to run applications, batch jobs, and functions at scale, without the hassle of managing infrastructure. It automatically handles provisioning, scaling, networking, and security, letting you focus on writing code instead of managing servers. - -Among its workload types are **[functions](https://cloud.ibm.com/docs/codeengine?topic=codeengine-cefunctions)**, which provide a lightweight, event-driven execution model. Code Engine functions currently support Node.js and Python [runtimes](https://cloud.ibm.com/docs/codeengine?topic=codeengine-fun-runtime), making them ideal for serving APIs, processing events or, as we'll explore in this post serving static web content. - -When deploying Single Page Applications (SPAs) to the cloud, you typically face a choice: use a full application server with all its overhead, or manually build your frontend and figure out how to serve static files. What if you could skip both the complexity and the manual steps? - -Code Engine Functions offer a compelling middle ground. Serverless, pay-per-use, and surprisingly simple for static content. But the real magic happens when you eliminate the build step from your deployment workflow entirely. - -In this post, we'll explore how to deploy any Single Page Application—whether it's Angular, React, Svelte, Vue, or any other framework—as a Code Engine function. This approach lets you enjoy the benefits of serverless deployment—automatic scaling, pay-per-use pricing, and zero infrastructure management—while keeping your deployment workflow dead simple: just point Code Engine at your source code, and it handles the build automatically. - -## The Problem with Traditional SPA Deployment - -Most SPA deployment workflows look like this: - -1. Build your frontend locally (`npm run build`) -2. Upload the build artifacts to object storage or a CDN -3. Configure routing rules for client-side navigation -4. Set up cache headers manually -5. Hope you didn't forget to rebuild before deploying - -This works, but it's error-prone. You might deploy stale builds, forget to update dependencies, or misconfigure cache headers. And if you're working with multiple frameworks or projects, each one has its own quirks. - -## A Better Approach: Build During Deployment - -What if the build happened automatically during deployment, using the exact source code you're deploying? That's the approach this solution takes. - -Here's the complete deployment flow: - -```bash -# Create a new function -ibmcloud ce function create \ - --name my-static-app \ - --runtime nodejs-24 \ - --build-source . - -# Or update an existing one -ibmcloud ce function update \ - --name my-static-app \ - --build-source . -``` - -That's it. No separate build step. No manual file copying. Just point Code Engine at your repository, and it handles the rest. - -## How It Works - -### Prerequisites - -Before you begin, make sure you have: - -- **IBM Cloud account** with Code Engine access ([IBM Cloud account](https://cloud.ibm.com/registration), ) -- **Code Engine project** created in your IBM Cloud account ([Code Engine getting started](https://cloud.ibm.com/docs/codeengine?topic=codeengine-getting-started)) -- **IBM Cloud CLI & Code Engine CLI plugin** installed and configured ([installation guide](https://cloud.ibm.com/docs/cli)) -- **Basic familiarity** with npm and your chosen frontend framework - -### The Function Wrapper - -The magic happens thanks to a simple function wrapper that we provide, consisting of just three files. These files are included in the [Code Engine Sample repository](https://github.com/IBM/CodeEngine/tree/main/function-spa): - -1. **`main.js`** - The function entrypoint that serves your static files -2. **`package.json`** - The function definition with a postinstall hook -3. **`build-spa.sh`** - The build script that runs during deployment - -When you deploy to Code Engine, you're actually deploying this function wrapper alongside your SPA source code. The wrapper handles everything: building your frontend, serving the files, routing requests, and setting cache headers. - -From a development perspective, your repository structure looks like this: - -``` -your-repo/ -├── main.js # As provided from the Repo (serves static files) -├── package.json # As provided from the Repo (with postinstall hook) -├── build-spa.sh # As provided from the Repo (runs during deployment) -└── my-frontend/ # Your SPA source code folder - ├── package.json # Frontend dependencies - ├── src/ # Frontend source files - └── ... # Other frontend files -``` - -The root contains the function wrapper files ([main.js](https://github.com/IBM/CodeEngine/blob/main/function-spa/main.js), [package.json](https://github.com/IBM/CodeEngine/blob/main/function-spa/package.json) and [build-spa.sh](https://github.com/IBM/CodeEngine/blob/main/function-spa/build-spa.sh)), and your SPA lives in a subdirectory. During deployment, the build script automatically detects your frontend folder, builds it, and places the output in the root `dist/` directory. - -**These three function wrapper files (`main.js`, `package.json`, and `build-spa.sh`) can be directly copied and used for your own SPA projects without modification.** They're designed to be framework-agnostic and work out of the box with any frontend that builds to static files. If you have specific requirements—such as custom routing logic, additional MIME types, or different build output locations—you can adapt these files to suit your needs while maintaining the core deployment workflow. - -The secret is in the `package.json` postinstall hook: - -```json -{ - "name": "static-content-function", - "version": "1.0.0", - "main": "main.js", - "scripts": { - "postinstall": "./build-spa.sh" - } -} -``` - -When Code Engine builds your function, it runs `npm install`. After installation completes, the postinstall hook triggers `build-spa.sh`, which: - -1. **Detects your frontend** - Finds the first non-hidden directory (excluding `node_modules` and `dist`) -2. **Installs dependencies** - Runs `npm ci` or `npm install` in that directory -3. **Builds the frontend** - Executes `npm run build` -4. **Locates output** - Finds `index.html` in either `dist/` or `build/` -5. **Copies to root** - Places build artifacts in the root `dist/` directory -6. **Cleans up** - Removes the source frontend directory to keep the function package small - -The final function package contains only three things: - -``` -function-package/ -├── main.js # Function entrypoint -├── package.json # Function definition -└── dist/ # Your built frontend - ├── index.html - ├── assets/ - └── ... -``` - -At runtime, the function serves files directly from `dist/` when they exist, falls back to `index.html` for paths without extensions (enabling client-side routing), and returns 404 for missing assets. Binary files like images and fonts are automatically base64-encoded, while path traversal attempts are sanitized and only GET requests are allowed for security. - -## Using Any Frontend Framework - -This approach works with any frontend framework or build tool that produces static files. - -### Quick Start - -To get started quickly: - -1. **Clone the repository** - ```bash - git clone https://github.com/IBM/CodeEngine.git - cd CodeEngine/function-spa - ``` - -2. **Add your SPA to a subdirectory** - - Place your frontend project in a subdirectory (e.g., `my-app/`) - - Ensure it has `npm run build` configured in its `package.json` - -3. **Deploy to Code Engine** - ```bash - ibmcloud ce function create --name my-app --runtime nodejs-24 --build-source . - ``` - -**Or use the included quick-start scripts:** - -The repository includes three quick-start scripts demonstrating the workflow: - -```bash -./run-angular # Creates Angular project (SSR disabled, routing enabled, standalone components) -./run-react # Creates React project with Vite (TypeScript, fast builds, modern tooling) -./run-svelte # Creates Svelte project with Vite (minimal bundle, reactive components) -``` - -Each script creates a new project in a subdirectory, checks if the function already exists, runs either `function create` or `function update`, and waits for deployment to complete. These examples show that whether you're using Angular, React, Svelte, Vue, Solid, Qwik, or any other framework, the deployment process is identical. - -To use your own frontend, it must meet these requirements: - -1. **Produces static files** - The output must be plain HTML, CSS, and JavaScript -2. **Has a build script** - Must have `npm run build` in `package.json` -3. **Outputs to `dist/` or `build/`** - The build script should create one of these directories -4. **Includes `index.html`** - The build output must contain an `index.html` file - -The deployment workflow is straightforward: - -1. Create your SPA project in a subdirectory alongside the function wrapper files (`main.js`, `package.json`, `build-spa.sh`) -2. Develop locally using your framework's dev server -3. Test that `npm run build` works and produces the expected output -4. Deploy with `ibmcloud ce function create` or `update` - -The build process automatically detects your frontend, builds it during deployment, and packages everything correctly. -This approach doesn't interfere with your local development workflow—you can continue using your framework's hot reload, dev server, and all existing best practices and tooling. -Simply develop locally as usual, test that `npm run build` produces static files, then deploy with the Code Engine command. You never need to manually copy files or worry about build artifacts; the deployment process handles everything. - -## Conclusion - -Deploying SPAs to Code Engine Functions eliminates the manual build step while keeping your deployment simple and cost-effective. The build happens automatically during deployment, using the exact source code you're deploying. The function runtime is minimal, secure, and handles all the routing and caching logic you need. - -Whether you're deploying an Angular dashboard, a React demo, or a Svelte tool, the workflow is the same: develop locally, then deploy with a single command. No build artifacts to manage, no manual file copying, no configuration drift. - -Code Engine Functions offer a sweet spot between different deployment options. Compared to Code Engine Applications, functions are more cost-effective for low-traffic SPAs since you only pay per invocation rather than for always-running containers, and functions have fast cold starts. Compared to Object Storage with CDN, functions automate the build process and handle routing in code, eliminating manual builds and complex routing configuration. And compared to traditional hosting with fixed monthly costs and server management overhead, functions provide pay-per-use pricing with automatic deployment and zero server management. - -This approach is ideal for internal tools, demos and previews, customer-specific frontends, small static bundles, and cost-sensitive projects. However, it's not suited for applications requiring server-side rendering (SSR), backends with complex API logic (use Code Engine applications instead), sites with extremely high traffic (consider a CDN), or applications needing WebSocket connections or long-running processes. - -The complete source code is available at the [Code Engine Sample Repository](https://github.com/IBM/CodeEngine/blob/main/function-spa), including the quick-start scripts for Angular, React, and Svelte. -Now its your turn try it out and see how simple SPA deployment can be. - ---- - -*This approach works with any frontend framework that builds to static files. The examples use Angular, React, and Svelte, but Vue, Solid, Qwik, and others work just as well.* diff --git a/data/authors/jeremiaswerner.toml b/data/authors/jeremiaswerner.toml deleted file mode 100644 index cbeee3810..000000000 --- a/data/authors/jeremiaswerner.toml +++ /dev/null @@ -1,9 +0,0 @@ -name = "Jeremias Werner" -bio = "Senior Architect (STSM) for IBM Cloud Code Engine" -image = "jeremiaswerner.jpg" - -# Add external links (this will automatically generate clickable icons under the author name) -[links] - linkedin = "https://www.linkedin.com/in/jeremias-werner" - github = "https://github.com/jeremiaswerner" - diff --git a/data/authors/joachimjordan.toml b/data/authors/joachimjordan.toml deleted file mode 100644 index 21e48680e..000000000 --- a/data/authors/joachimjordan.toml +++ /dev/null @@ -1,6 +0,0 @@ -name = "Joachim Jordan" -bio = "Tech Lead Code Engine Platform @ IBM Cloud" -image = "joachimjordan.jpg" - -# Add external links (this will automatically generate clickable icons under the author name) -[links] diff --git a/data/authors/josip-ledic.toml b/data/authors/josip-ledic.toml deleted file mode 100644 index 4b05c40c7..000000000 --- a/data/authors/josip-ledic.toml +++ /dev/null @@ -1,5 +0,0 @@ -name = "Josip Ledic" -bio = "Software Engineer @ IBM Cloud Code Engine" - -# Add external links (this will automatically generate clickable icons under the author name) -[links] diff --git a/data/authors/lukeroy.toml b/data/authors/lukeroy.toml deleted file mode 100644 index 5815edd52..000000000 --- a/data/authors/lukeroy.toml +++ /dev/null @@ -1,8 +0,0 @@ -name = "Luke Roy" -bio = "Cloud Software Engineer @ IBM Cloud Code Engine" -image = "lukeroy.jpg" - -# Add external links (this will automatically generate clickable icons under the author name) -[links] - linkedin = "https://www.linkedin.com/in/luke-roy" - github = "https://github.com/lukeroy" diff --git a/data/authors/saschaschwarze.toml b/data/authors/saschaschwarze.toml deleted file mode 100644 index 6e4b3c161..000000000 --- a/data/authors/saschaschwarze.toml +++ /dev/null @@ -1,8 +0,0 @@ -name = "Sascha Schwarze" -bio = "Senior Software Enginer @ IBM Cloud Code Engine" -image = "saschaschwarze.jpg" - -# Add external links (this will automatically generate clickable icons under the author name) -[links] - github = "https://github.com/SaschaSchwarze0" - diff --git a/data/authors/uwefassnacht.toml b/data/authors/uwefassnacht.toml deleted file mode 100644 index b6a9257b1..000000000 --- a/data/authors/uwefassnacht.toml +++ /dev/null @@ -1,9 +0,0 @@ -name = "Uwe Fassnacht" -bio = "Product Manager for IBM Cloud Code Engine" -image = "uwefassnacht.jpg" - -# Add external links (this will automatically generate clickable icons under the author name) -[links] - linkedin = "https://www.linkedin.com/in/uwefassnacht" - github = "https://github.com/uwefassnacht" - diff --git a/experimental/serverless-fleets/README.md b/experimental/serverless-fleets/README.md deleted file mode 100644 index a9dbfba6f..000000000 --- a/experimental/serverless-fleets/README.md +++ /dev/null @@ -1,5 +0,0 @@ -# Simplify and optimize large-scale parallel computation with Serverless Fleets - -Serverless Fleets has been GA'd and so the samples and tutorials can be found under a new URL - -https://github.com/IBM/CodeEngine/blob/main/serverless-fleets diff --git a/go.mod b/go.mod deleted file mode 100644 index 2217736f4..000000000 --- a/go.mod +++ /dev/null @@ -1,3 +0,0 @@ -module github.com/IBM/CodeEngine - -require github.com/nunocoracao/blowfish/v2 v2.103.0 diff --git a/hugo.toml b/hugo.toml deleted file mode 100644 index b29c009c0..000000000 --- a/hugo.toml +++ /dev/null @@ -1,65 +0,0 @@ -baseURL = "https://ibm.github.io/CodeEngine/" -title = "Code Engine Blog" -locale = "en-us" - -[module] - path = "github.com/IBM/CodeEngine" - [[module.imports]] - path = "github.com/nunocoracao/blowfish/v2" - -[outputs] - home = ["HTML", "RSS", "JSON"] - -# --- GLOBAL THEME PARAMETERS --- -[params] - enableCodeCopy = true - colorScheme = "slate" # Options: "blowfish", "congo", "forest", "ocean", "sunset", "fire", "terminal", "github" - -[params.main] - mainSections = ["posts"] - -[params.main.logo] - src = "code-engine-logo.svg" - alt = "IBM Code Engine Logo" - disabled = false - -[params.header] - layout = "sticky" - logoType = "logo" - -[taxonomies] - tag = "tags" - category = "categories" - author = "authors" # Explicitly instructs Hugo to build index pages for authors - -[params.homepage] - layout = "card" - showRecent = true - showRecentItems = 6 - cardView = true - -[params.article] - showDate = true - showReadingTime = true - showThumbnail = true - showHero = true - showAuthor = true # Appears as a clean line right below the title - showAuthorBottom = true # Appears as a rich bio card at the end of the post - showTaxonomies = true - showAuthorsBadges = true - -[params.list] - showDownloads = false - showReadingTime = true - showTableOfContents = false - showTaxonomies = true # Displays the interactive global tag cloud filter on list views - showViews = true # Adds a slick grid/list toggle view option for readers - -[params.search] - enable = true - showOnHeader = true - -# --- SYNTAX HIGHLIGHTING (Required for copy script) --- -[markup] - [markup.highlight] - noClasses = false diff --git a/kafka-observer/verify b/kafka-observer/verify new file mode 100644 index 000000000..b3cb4f125 --- /dev/null +++ b/kafka-observer/verify @@ -0,0 +1,6 @@ +#!/bin/bash +set -euxo pipefail + +docker build --platform linux/amd64 -f Dockerfile.consumer . + +docker build --platform linux/amd64 -f Dockerfile.observer . \ No newline at end of file diff --git a/kafka/verify b/kafka/verify new file mode 100644 index 000000000..b9cc8d228 --- /dev/null +++ b/kafka/verify @@ -0,0 +1,6 @@ +#!/bin/bash +set -euxo pipefail + +docker build --platform linux/amd64 -f Dockerfile.receiver . + +docker build --platform linux/amd64 -f Dockerfile.sender . \ No newline at end of file diff --git a/quantum/qiskit-jupyter-app/README.md b/quantum/qiskit-jupyter-app/README.md index 031704246..f6a2dfc3e 100644 --- a/quantum/qiskit-jupyter-app/README.md +++ b/quantum/qiskit-jupyter-app/README.md @@ -1 +1 @@ -See ![](../../content/posts/qiskit-jupyterlab-on-code-engine/) \ No newline at end of file +See [Quantum Notebooks in the Cloud: Run Qiskit in JupyterLab on IBM Cloud Code Engine](https://ibm.github.io/CodeEngine/posts/qiskit-jupyterlab-on-code-engine/) \ No newline at end of file diff --git a/quantum/qiskit-jupyter-app/verify b/quantum/qiskit-jupyter-app/verify new file mode 100644 index 000000000..2b74dceb4 --- /dev/null +++ b/quantum/qiskit-jupyter-app/verify @@ -0,0 +1,4 @@ +#!/bin/bash +set -euxo pipefail + +docker build --platform linux/amd64 . \ No newline at end of file diff --git a/static/luke-roy-ibm.jpg b/static/luke-roy-ibm.jpg deleted file mode 100644 index 0a93fb89d..000000000 Binary files a/static/luke-roy-ibm.jpg and /dev/null differ diff --git a/static/uwefassnacht.jpg b/static/uwefassnacht.jpg deleted file mode 100644 index ce7364877..000000000 Binary files a/static/uwefassnacht.jpg and /dev/null differ