# Creating Custom Environment
A custom environment is an environment that you can create for your organization, based on one of the available katacoda base images. It is commonly used to pre-cached docker images, installing tools, and creating files that are common across all the scenarios.
NOTE: This is only available with a Katacoda Subscription.
# Base images
These are the base images available at the moment:
|Ubuntu 18.04||Docker installed and running||ubuntu1804|
|Centos 7||Docker installed and running||centos7|
|Kubernetes Cluster 1.16 (Ubuntu)||2 nodes with kubeadm installed, nothing running. Based on Ubuntu 16.04.||kubernetes-master-ubuntu1604-1-16 and kubernetes-node-ubuntu1604-1-16|
|Kubernetes Cluster 1.16 (CentOS)||2 nodes with kubeadm installed, nothing running. Based on CentOS 7.||kubernetes-master-centos7-1-16 and kubernetes-node-centos7-1-16|
|Minikube||1 node with minikube 1.8.1, nothing running. Based on Ubuntu 18.04.||minikube|
The id of the base image will be defined in the file
katacoda.yaml in the directory corresponding to your environment.
# Creating a new Environment
Create a directory called
environments in the repository. Within there you can have a environment, such as
exampleenv1. Within the directory, create a new directory called
build. This directory will contain your build scripts, prefixed with a number to indicate order. For example:
You can have as many scripts as you want, and they will execute in order as listed, so we recommend to number it.
Inside of the directory corresponding to your environment, create a
katacoda.yaml file, and define the base image.
The directory structure should be:
├── exampleenv1 │ ├── build │ │ ├── 1_installpackages.sh │ │ ├── 2_pulldockerimages.sh │ │ └── 3_pulldemos.sh │ └── katacoda.yaml
You can see an example for exampleenv1. In this case, the build scripts are based on Ubuntu 16,04, install additional packages and pull Docker Images.
Once you commit and push the changes, you can see the logs at https://dashboard.katacoda.com/environments/builds/
To use the environment, the imageid name would be
<orgname-environmentdirectoryname>, for example if organization is katacoda, the environment will have the id
katacoda-exampleenv1. The custom environments are available on https://beta.katacoda.com/ for testing. Once happy, you can request the promotion via the dashboard or send us an email to email@example.com.
# Multi-node environments
This is an example of the custom environment for kubernetes 1.16.
Create is a directory called
kubernetes-cluster-1-16, inside of it, you should have a directory for the master and another directory for the node. Inside of the directories
node there should be the
katacoda.yaml file indicating the base image.
katacoda.yaml file defined as root level is not used at the moment, and it is prepared for future use.
The directory structure should be:
├── kubernetes-cluster-1-16 │ ├── master │ │ ├── build │ │ │ └── 1_init.sh │ │ └── katacoda.yaml │ └── node │ ├── build │ │ └── 1_init.sh │ └── katacoda.yaml
For each master and node, create a
build directory where you will put your build scripts. As an example, you can see at kubernetes custom environment. In this case, the build script is based on Ubuntu 16,04, to install kompose.
# Running Commands Before User Connects
With a paid subscription and customised environments, the environment can be can be customised to preboot components, such as certain Containers or Kubernetes Deployment.
To configure the environment create a file called
/opt/configure-environment.sh that will be executed when the environment starts.
For example, the following script would start the nginx container in the background when the environment had started.
cat << EOF > /opt/configure-environment.sh #!/bin/bash docker run -it -d --name=http -p 80:80 nginx EOF chmod +x /opt/configure-environment.sh
NOTE: On beta the script will be run when the session starts so may take a few moments to reflect the end results. In production this is optimised away so users don't have to wait.