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 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.
Code Engine requires that you use an IBM Cloud "paid account", even if you don't plan on going beyond the free tier.
The easiest way to run these are via the IBM Cloud 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:
$ ibmcloud plugin update --all --force
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
) - Code Engine plugin (
ce
) - Cloud Object Storage plugin (
cos
) - Event Streams plugin (
es
) for samples which use IBM Event Streams (Kafka) docker
if you choose to build the images yourself. For novices, skip this.
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.
If you need, or want, to clone this repo simple execute:
$ 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:
$ 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 already created. If you do not, go ahead and create one like this:
$ ibmcloud ce project create --name demos
With that, cd
into the directory of interest, and read the README to see how
to get started.
-
Gallery
Walks through the complete growth path of a solution from the prototype stage through to production - showcasing how to the various components, like applications, functions and jobs can be work together to implement a solution. -
Thumbnail Generator
Walks through the complete growth path of an application from the prototype stage through to production - demonstrating how to switch from an in-app processor to one where the data is persisted and processed via an event-driven architecture. -
Metrics Collector
Re-usable asset that helps to gain insights on the CPU and memory consumption of apps, jobs and builds.
The samples are grouped by the main category of functionality that it is demonstrating.
- hello
Very basic "hello world!" type of application written in Node.js. Start here! - helloworld
Similar to hello except this is written in golang and adds a few bells-n-whistles to allow you to control what it does when invoked. - auth
This shows how to setup an nginx proxy in-front of a private application to ensure that only authorized people can access it. - bind-app
This will create an instance of Event Streams in the IBM Cloud and then ask Code Engine to bind it to an Application so we can access it from the App. The credentials, etc. will be injected into the App via environment variables. - cecli
Show how to invoke the Code Engine CLI from within an App. This can be used to then start additional Code Engine resources (Apps/Jobs) dynamically. Same logic could be used in Batch Jobs. - sessions
Starts a stateful application that scales based on load. The state is kept in an instance of Redis, also running within Code Engine. Demonstrates the use of non-http components and private networking between components. - websocket Shows how to interact with an Application via WebSockets.
- helloworld
This is another simple Batch Job sample, similar to the previous one, but shows how to use environment variables to modify the behavior of the runtime of the job. - cronjob
This will create a Batch Job that will be invoked based on a cron event. Meaning, it'll be executed based on a timer. - app2job
This will show how to submit a Job from an Application based on an incoming HTTP request to the Application. - function2job
This will show how to submit a Job from a Function based on an incoming HTTP request to the Function. - bind-job
This will create an instance of Event Streams in the IBM Cloud and then ask Code Engine to bind it to a Batch Job so we can access it from the Job. The credentials, etc. will be injected into the Job via environment variables. - job2app
This will demostrate how to create a simple Batch Job and how to have it communicate with an Application running within the same project. - job2vsi
The sample shows how a job can be used to spawn Virtual Server Instances (VSIs) in your IBM Cloud account and run workload on them.
- function-inline-nodejs This example shows how to create simple inline NodeJS function
- function-inline-python This example shows how to create simple inline Python function
- function-codebundle-nodejs This example shows how to create NodeJS functions with additional modules
- function-codebundle-python This example shows how to create Python functions with additional modules
- function-http-nodejs This example shows how to create NodeJS functions with can perfome a http request without additional modules
- function-http-python This example shows how to create Python functions which can perfome a http request without additional modules
- cron
This will show how to setup a simple Cron Event Source and send its events to an Application. - cronjob
This will create a Batch Job that will be invoked based on a cron event. Meaning, it'll be executed based on a timer. - cos-event
This will show how to setup a COS Event Source and send its events to an Application. - github
This sample will show how to get events from Github (via its webhooks) delivered to a Code Engine Application. - kafka
This sample shows how to create a Kafka subscription to automatically have messages in a Kafka instances delivered to an application. - kafka-observer
This provides a sample implementation of the observer pattern, which is a native approach to consume Kafka messages in IBM Cloud Code Engine. - cloudant-change-listener
This is a sample of a Cloudant Databases changes listener that continously listen on all changes in a database. For each change a Code Engine function is invoked
- configmaps-env
Shows how to define and inject a ConfigMap as environment variables into an Application. - configmaps-vol
Shows how to define and inject a ConfigMap as a volume into an Application. - secrets-env
Shows how to define and inject a Secret as environment variables into an Application. - secrets-vol
Shows how to define and inject a Secret as a volume into an Application.
These are designed such that they should be able to be fully built and used by anyone. Unless otherwise noted the overall pattern that will be followed is:
- a
build
script shows how each container image used in the sample is built. By default, the script will push the image to theicr.io/codeengine
namespace, so to use this yourself you'll need to set theREGISTRY
environment variable to your own registry and/or namespace. Also, you MUST use a registry that allows for anonymous/public downloads of your images, since as of now (to keep the scripts simple) they do not deal with private registry access tokens by default.- However, if you do decide to push your images into a registry that
is private, you'll need to modify the
run
scripts to specify the--registry-secret
option on the app and job creation commands to point to your secret that includes the registry credentials.
- However, if you do decide to push your images into a registry that
is private, you'll need to modify the
- a
run
script will execute the sample. Most will also include logic to verify the output to ensure everything is working as expected. As withbuild
, it will default to using theicr.io/codeengine
container images, so to use your own you'll need to set theREGISTRY
environment variable. This means that you should be able to just executerun
without runningbuild
first, and it'll just use the pre-built images fromicr.io/codeengine
.- invoking
run clean
should clean up from any previous execution without re-running the sample.
- invoking
- IBM Cloud Code Engine
- For questions/comments join us on Slack:
Register | Login and join us on the #code-engine channel