Environment creation
|
Note |
|---|---|
This page is actively maintained by the Grid'5000 team. If you encounter problems, please report them (see the Support page). Additionally, as it is a wiki page, you are free to make minor corrections yourself if needed. If you would like to suggest a more fundamental change, please contact the Grid'5000 team. | |
This page presents in details how to create a Grid'5000 environment. An environment is an operating system image that can be deployed on hardware nodes (bare metal) using kadeploy3.
Grid'5000 provides bare-metal as a service for experimenting on distributed computers, thanks to the kadeploy service. While kadeploy handles the efficient deployment of a user's customized system (also named environment in the Grid'5000 terminology) on many nodes, companion tools allow building such custom systems environments. Hence, this page describes the Grid'5000 environment creation processes, with the several methods for doing it, and helpful tools.
Introduction: the several ways for preparing a custom system environment
There are different ways to prepare a system environment for experiments:
(1)A first way consists in deploying a provided environment, for instancedebian11-big, and adding software and custom configurations to it after the initial deployment. That every time a new experiment is run (new deploy job). While it can be relevant, it has an obvious bias: the post-deployment setup is not factorized and must be redone every time and on all nodes.(2)A second way consists in building a master system environment with all the wanted customizations, then deploying that pre-built environment on the experiment nodes. This way, the environment preparation is only done once for all times and all nodes: it is factorized.
Once again, building such a customized master system environment can be achieved in different ways:
(2-a)A first way consists in deploying an already provided environment (such as one of the Grid'5000 supported reference environments) on one node, doing some customizations on that node, then finally saving the operating system of the node as a master environment image. Then, deploy it on all the nodes of an experiment. This usually involves thetgz-g5kcommand to create the master environment image (tarball).(2-b)A second way consists in building the master environment to deploy on all the nodes of an experiment from a recipe which describes the whole system environment construction process. This obviously allows for the reconstructibility and sharing of the environment, hence it helps the reproducibility of the experiment. This involves the same build process that is used to produce the Grid'5000 reference environments, using thekameleontool.
|
|
Note |
|---|---|
Even though it is somehow out of context in this page, we can also mention the use of the
debian11 standard environment as base system on the nodes of the experiment, which may include some unnecessary complexity or limitations
| |
In the remaining of this page, (1) will not be detailed: it is let to the user to choose a tool to deploy software and configurations on running systems, such as clush, taktuk, ansible, etc.
The next two paragraphs give detailed technical howtos for customizing existing Grid'5000 environments, first following way (2-a), then way (2-b).
About Grid'5000 supported environments
While building a system environment from scratch (only taking a generic OS installation media as a base) may be doable, it is technically extremely difficult (see the last section of this page). Most Grid'5000 users should rather create customized environments on top of existing works, already done for Grid'5000.
The Grid'5000 technical team provides several reference environments, which a user's customized environment can be built on top of. They are maintained in a git repository that includes both the kameleon recipes and the puppet recipes (Kameleon invokes puppet for most of the environment's configuration). The list of packages installed in each environment is managed in the g5k-meta-packages repository.
More information on Grid'5000 reference environments can be found on the Getting started page.
Of course, a user can also build a new customized environment on top of another user's customized environment.
About environment postinstalls
This page concentrate on the generation of the image and description part of environments. Another important part of an environment is the postinstall. Most Grid'5000 environments use a same postinstall which is named g5k-postinstall. Users may however write their own postinstall to replace it or to add as an additional postinstall.
Postinstalls are documented in Advanced_Kadeploy#Customizing_the_postinstalls.
Creating an environment images using tgz-g5k
In this section, following the (2-a) way described above, we explain how to extend an existing Grid'5000 environment by first deploying it on a machine with kadeploy3, then bringing customization to that machine, and finally archiving the operating system of the machine with tgz-g5k to create a new environment image.
Deploy the existing environment on a machine
First, we have to create the deploy job, to reserve a machine on which we will deploy the existing environment of our choice, which our customized environment will be based on.
|
|
Note |
|---|---|
At this stage, it is wise to choose a Grid'5000 site and cluster that is not too loaded, furthermore using rather old hardware is of special interest because newer hardware usually has significantly longer boot time → see the Hardware page. | |
We do an interactive job (-I), of the deploy type (-t deploy), on only one machine (-l host=1). We will give ourselves 3 hours with -l walltime=3.
|
frontend:
|
oarsub -I -t deploy -l host=1,walltime=3 |
The interactive job opens a new shell on the frontend (careful: the job ends when exiting that shell).
The hostname of the reserved machine is stored in the $OAR_FILE_NODES file which is used by default by Kadeploy. So we can deploy the reference environment of our choice (or another user's environment that we would like to extend) with kadeploy3:
|
|
frontend:
|
kadeploy3 debian11-base |
(if the chosen environment is not registered in kaenv3, see the -a option of kadeploy3 to point to a environment description file).
Customize the environment
Once the deployment has run successfully, we can connect to the machine using ssh as root without password, and do any customization using shell commands.
|
|
frontend:
|
ssh root@hostname |
You can therefore update your environment (to add any missing library you need, remove any package that you don't need in order to sizes down the image and possibly speeds up the deployment process, etc.)
Note: When you are done with the customization, mind clearing temporary files or caches to save disk space.
Archive the environment image
We can now archive the customized environment, using tgz-g5k to create a Grid'5000 environment image from the filesystem of the machine. The environment image is a tarball of the filesystem of the OS with some adaptations.
|
|
frontend:
|
tgz-g5k -m hostname -f ~/environment_image.tar.zst |
This will create a file named environment_image.tar.zst in your home directory on the frontend.
|
|
Note |
|---|---|
About
| |
Create the environment description file
The new environment image cannot be deployed directly: the image is only one part of an environment. An environment is described by a YAML document. To use the new image, it must be referred by an environment description, so that deploying that environment uses the new image. Note that the environment includes also other information such as the postinstall script and the kernel command line for instance, which can be changed independently from changing the environment image.
The easiest way to create a description for your new environment is to modify the description of the environment it is based on.
Since we used the debian11-base reference environment, we can retrieve its description using the kaenv3 command and save it to a file. Then we'll use it as a base for the description of our customized environment.
|
|
frontend:
|
kaenv3 -p debian11-base > my-custom-environment.yaml |
|
|
Note |
|---|---|
About the architecture: | |
|
|
Note | |||
|---|---|---|---|---|
About the debian std environments: The debian std (e.g.
g5k-postinstall command, which must not include --restrict-user std in your environment's description.
| ||||
We now edit the file to change the environment name, version, description, author, and so on. The image file entry must of course be changed to point to our new environment image tarball file. Since it is stored locally in our home directory, the path can be a simple absolute path (remove the server:// prefix). If the image is placed in your ~/public directory, an HTTP URL can alternatively be used (e.g. http://public.SITE.grid5000.fr/~jdoe/environment_image.tar.zst, replace SITE by the actual site). Finally, the visibility line should be removed or its value changed to shared or private.
---
name: my-debian
version: 1
arch: x86_64
description: my customized environment based on debian 10 (buster) - base
author: john@doe.org
visibility: shared
destructive: false
os: linux
image:
file: /home/jdoe/environment_image.tar.zst
kind: tar
compression: zstd
postinstalls:
- archive: server:///grid5000/postinstalls/g5k-postinstall.tgz
compression: gzip
script: g5k-postinstall --net debian
boot:
kernel: "/vmlinuz"
initrd: "/initrd.img"
kernel_params: ""
filesystem: ext4
partition_type: 131
multipart: false
|
Warning |
|---|---|
A local path for the tarball (no leading | |
Once this is done, our customized environment is ready to be deployed (in a deploy job) using:
|
|
frontend:
|
kadeploy3 -a my-custom-environment.yaml |
(This kind of deployment is called anonymous deployment because the description is not yet in the Kadeploy3 environment registry. It is particularly useful when working by iteration on the environment, thus having to recreate the environment image several times. Otherwise, since registered environments are checksummed, changing the image file requires updating the registration every time with kaenv3)
Once your customized environment is ready, it's optionally the time to add it to the Kadeploy3 environment registry:
|
|
frontend:
|
kaenv3 -a my-custom-environment.yaml |
Assuming you set the name field in the environment description to "my-debian", it will then be deployable using the following command:
|
|
frontend:
|
kadeploy3 my-debian |
If the visibility is set to shared, your environment will show up in the list of available registered environment for any user, using kaenv3 -l -u your_username.
|
|
Warning |
|---|---|
The registration of the environment does not make a copy of the environment image and postinstall files! Do not remove them or the environment will be broken. Also, environments registered by users are not automatically replicated on all sites (there is one kadeploy registry per site). | |
Creating an environment from a recipe using kameleon
In this section, following the (2-b) way described above, we explain how to build environments from recipes describing the whole creation process, rather than doing interactive modifications in command-line then use tgz-g5k to export the system to an image. With the method, all steps requested to build the environment are written, which helps traceability, reconstructability, and sharing.
There are actually different ways of writing recipes. The recipes of the Grid'5000 reference environment for instance describe the whole process of installation of the operating system from scratch using the installer of the target Linux distribution. Also, the Debian stable environments which are provided in several variants use Puppet for most of the configuration of the system. However, while building from scratch and using Puppet may look very nice, it is also complex and longer to execute.
As a result, we present a method in this documentation that is simpler and closer to what is actually done when using tgz-g5k:
- The recipe will first retrieve the operating system image (tarball) of an existing Grid'5000 environment and run it a VM. That's bootstrap stage.
- Then, the recipe will allow any customizations of the VM's operating system in the setup stage.
- Finally, the export stage will create a new environment from the customized operating system, ready to be consumed by kadeploy.
Recipes are written for and processed by a tool named kameleon, that do the actual build of the environment. Kameleon is a powerful utility to generate operating system images (environments in the Grid'5000 context) from recipes.
A kameleon recipe is composed of a main YAML file: the recipe. That recipe possibly depends on other YAML files: some recipes it extends and some macro steps. It also depends on various other files: data, helper scripts,....
Kameleon provides features such as context isolation and interactive breakpoints. Context isolation means that kameleon can run a build process without altering the operating system from where the tool is called itself (kameleon typically uses qemu VMs for the build). Kameleon does not need to run as root.
See the Kameleon website for more information on the tool.
Preparing the workspace to use kameleon
For the work with kameleon, we suggest creating a fresh directory that will contain our recipes and all dependencies. Optionally, that directory can of course be versioned in a new git project, in order to keep track of any changes made.
|
|
node:
|
mkdir ~/my_recipes && cd ~/my_recipes |
|
|
Warning |
|---|---|
In the remaining of this document, kameleon commands are always run on a Grid'5000 machine in a regular job (not of type deploy), not on the personal workstation, and never on Grid'5000 frontends. The root privilege is not required to build an environment with kameleon (except on PPC64 machines/the drac cluster where | |
First we create an interactive job to reserve a node where to run the kameleon commands:
|
|
frontend:
|
oarsub -I |
Kameleon is preinstalled on the nodes.
We then install the repository of Grid'5000 recipes:
|
|
node:
|
kameleon repository add grid5000 https://gitlab.inria.fr/grid5000/environments-recipes.git |
In case you already installed the repository previously, you may want to update it. To do so, run the following command:
|
|
node:
|
kameleon repository update grid5000 |
You can then list the available recipe templates with:
|
|
node:
|
kameleon template list |
Create the recipe of the new environment
The kameleon template list command shows all templates available in the Grid'5000 environment recipes repository.
- We see here the templates for Debian stable (9, 10, and 11) with their different variants.
- We also see the templates for other distributions with only the min variant.
- Finally, we see the template for a recipe that builds from an existing Grid'5000 environment → In this section, we use that one.
So we extend the grid5000/from_grid5000_environment/base recipe, by run the following command:
|
|
node ~/my_recipes:
|
kameleon new my_custom_environment grid5000/from_grid5000_environment/base |
We can now edit the new recipe file: my_custom_environment.yaml, and look at the global section. A lot of comments are provided to help adapt the recipe to our needs. The most important information to provide in the recipe is what existing environment we want to base our recipe on. This information must be provided in the grid5000_environment_import_name global variable. It must be set to one of the environments that are shown when running kaenv3 -l on a frontend. For instance we may choose to use debiantesting-x64-min. Most other global variables are commented (line begin with a #) because default values may be just fine. However, we may want to change some of those variables for instance to specify the user and version for a specific environment.
## Environment to build from
grid5000_environment_import_name: "debiantesting-min"
#grid5000_environment_import_user: "deploy"
#grid5000_environment_import_version: ""
|
|
Note | ||||||
|---|---|---|---|---|---|---|---|
Your recipe uses a template named
| |||||||
|
|
Note |
|---|---|
About the debian std environment: please note that customizing the debian std (e.g. | |
Once done, the important part is to bring our customization steps for the setup of our environment in the setup section (bootstrap and export should not require any changes).
See the Kameleon website for more information, notably a description of the recipe syntax (language) used in the YAML files.
|
|
Warning |
|---|---|
Grid'5000 uses its own recipes that take benefit from recipes provided by the Kameleon developers (by extending them). Please beware that the Kameleon website does not have an up to date description of the usage of Kameleon in Grid'5000. | |
|
|
Note |
|---|---|
About the execution contexts of the Kameleon commands: The Kameleon commands execute in one of the local, out or in contexts (e.g. exec_local, exec_in, ...).
| |
Let's show some examples.
First example: install the ffmpeg package
Let's assume we want to install the ffmpeg package in our environment.
We add a new step to the recipe, which is just a sequence of actions to execute. This basically gives a setup section in our recipe as follows:
setup:
- install_more_packages:
- install_ffmpeg:
- exec_in : apt-get update && apt-get install -y ffmpeg
exec_inmeans that the command will be executed with bash in the VM of the build process. See the kameleon documention for other commands.install_more_packagesis a macrostep, it can group one or several microstepsinstall_ffmpegis a microstep
It is mandatory to define the 2 levels of steps (macrostep and microstep) and respect the format of a correct YAML document, to have a working recipe.
Optionally a macrostep and its microsteps can also be defined in a separate file. For instance, we can create the ~/my_recipes/steps/setup/ directory hierarchy and the steps/setup/install_more_packages.yaml file inside, with the following content:
- install_ffmpeg:
- exec_in : apt-get update && apt-get install -y ffmpeg
Then use it in the recipe with just:
setup: - install_more_packages
(no : after install_more_packages, since the macrostep is defined in a separate file).
Second example: Install the NAS Benchmarks
The NAS benchmarks are commonly used to benchmark HPC applications using MPI or OpenMP. In this example, we will download and configure the NAS package and build the MPI FT benchmark.
To do so we will create a step file that will be called from the recipe in ~/my_recipe/steps/setup/NAS_benchmark.yaml.
You can notice that a Kameleon variable is used to define the NAS_Home.
- NAS_home: /tmp
- install_NAS_bench:
# install dependencies
- exec_in: apt-get -y install openmpi-bin libopenmpi-dev make gfortran gcc
- download_file_in:
- https://www.nas.nasa.gov/assets/npb/NPB3.3.1.tar.gz
- $$NAS_home/NPB3.3.1.tar.gz
- exec_in: cd $$NAS_home && tar xf NPB3.3.1.tar.gz
- configure_make_def:
- exec_in: |
cd $$NAS_home/NPB3.3.1/NPB3.3-MPI/
cp config/make.def{.template,}
sed -i 's/^MPIF77.*/MPIF77 = mpif77/' config/make.def
sed -i 's/^MPICC.*/MPICC = mpicc/' config/make.def
sed -i 's/^FFLAGS.*/FFLAGS = -O -mcmodel=medium/' config/make.def
- compile_different_MPI_bench:
- exec_in: |
cd $$NAS_home/NPB3.3.1/NPB3.3-MPI/
for nbproc in 1 2 4 8 16 32
do
for class in B C D
do
for bench in is lu ft
do
# Not all IS bench are compiling but we get 48 working
make -j 4 $bench NPROCS=$nbproc CLASS=$class || true
done
done
done
As in the previous example, we finally add the NAS_benchmark macrostep to the setup section of the recipe, taking as parameter the NAS_home variable.
setup:
- NAS_benchmark:
- NAS_home: /root
Third example: Add a file
Let's add a file to your image. You can access the steps/data
folder inside Kameleon recipes using the $$kameleon_data_dir variable.
In this example, we will add a script that clears logs in the image.
First, write a step that copies a script and executes it.
This step must be located at steps/clean_logs.yaml:
- script_path: /usr/local/sbin
- import_script:
- local2in:
- $$kameleon_data_dir/$$script_file_name
- $$script_path/$$script_file_name
- exec_in: chmod u+x $$script_path/$$script_file_name
- run_script:
- exec_in: $$script_path/$$script_file_name
|
|
Note |
|---|---|
In this step we are using the alias command local2in provided by Kameleon. See documentation of commands and alias for more details. | |
Here is an example of a cleaning script that must be copied in steps/data/debian_log_cleaner.sh.
#!/bin/sh # This is my cleaning script 'cause I don't trust G5K systemctl stop rsyslog rm -rf /var/log/*.log* rm -f /root/.bash_history
|
|
Note |
|---|---|
Script content does not really matter, it is an example. Of course, you can run these commands directly inside the recipe | |
Finally, we call that step by modifying the setup section of the recipe. We set the variables script_file_name to select the script in the data folder.
- clean_logs
- script_file_name: debian_log_cleaner.sh
Other examples
For more complex examples, you may look at the following tutorials:
Inspecting the recipe
To inspect our environment before launching the build:
- We can look at the information about the environment with
kameleon info:
|
|
node ~/my_recipes:
|
kameleon info my_custom_environment |
- We can look at what the build of the environment involves without actually building by running
kameleon build --dryrun:
|
|
node ~/my_recipes:
|
kameleon build --dryrun my_custom_environment |
Those commands are of great help to find out about the recipe's macrosteps and microsteps, files, variables, etc...
If any error is raised with those commands, it probably comes from a bad syntax in the recipe (e.g. bad YAML formatting).
Build and test
Once the recipe is written, we can launch the build. To do so, we just have to run following command:
|
|
node ~/my_recipes:
|
kameleon build my_custom_environment |
|
|
Warning |
|---|---|
Depending on different factors (e.g. the size of the image you are about to create (what variant), the hardware used (SSD or HDD)), the build process can last from a few minutes to a lot longer. | |
We end up with a build directory that contains the freshly build files we are interested in:
- File
build/my_custom_environment/my_custom_environment.dsc
- This is the description file of the new environment (this is a YAML file, the file extension does not really matter, be it
.dsc,.envor.yaml) - It can be used either directly with kadeploy to run the deployment without registering the environment.
The my_custom_environment.dsc file may need to be edited to set the image file path: use local:///home/yourlogin/my_recipe/build/my_custom_environment/my_custom_environment.tar.zst to point to a local file, but you may also specify an URL if you have put the file in your public directory (see below for an example with that).
After creating a new job of type deploy, we run the following kadeploy command from the frontend:
|
|
frontend:
|
kadeploy -a ~/my_recipe/build/my_custom_environment/my_custom_environment.dsc |
- Or to register the environment with
kaenv3, for later use with kadeploy.
|
|
frontend:
|
kaenv3 -a ~/my_recipe/build/my_custom_environment/my_custom_environment.dsc |
- File
build/my_custom_environment/my_custom_environment.tar.zst
- This is the tarball of our new environment, referred to in the environment description
The recipe also takes care of copying the environment files in your public directory. As a result it can also be deployed using and HTTP URL (replace SITE by the actual Grid'5000 site):
|
|
frontend:
|
|
|
Note | ||||||
|---|---|---|---|---|---|---|---|
The environment tarball can also be used directly, for instance with After installing docker on a reserved node with
Then run the docker container, for instance:
| |||||||
Of course, writing recipes, building the environment, and testing it may be a trial and error process requiring to loop over the different stages.
Please note that kameleon provides an interactive debugging of the recipe in case of errors or when breakpoints are inserted in the recipe. See comments in the recipes which give the syntax to add a breakpoint.
About the recipes of the Grid'5000 reference environments
Contrary to the recipe presented before which reuses the tarball of an existing environment, recipes of Grid'5000 reference environments are built from scratch using the target system installer, and use Puppet for the Debian stable environment. This section shows how to take benefit from those recipes in case the previous method does not suit the need.
|
|
Note |
|---|---|
Here is a summary of pros & cons of the 2 types of recipes
| |
We detail below how to work with the Grid'5000 reference environment recipes, first exploiting Puppet (for Debian stable recipes only), second without Puppet.
Working with a Grid'5000 reference environment recipe that uses Puppet
We present here how to extend a Grid'5000 recipe and use Puppet to bring some customizations in a traceable way.
As a reminder, Puppet is only used in the Debian stable environment recipes of Grid'5000. We will extend one of those.
The names of the Debian stable (Debian 10 and 11) recipe templates end by a word after a dash: that's the variant name. Variants are min, base, nfs, big (see above in this page for more details). Puppet is in charge of configuring the environment operating system with regard to the chosen variant. All variants are defined as Puppet classes that include each others in the following order:
min ⊂ base ⊂ nfs ⊂ big
This means that all changes made in the min class will affect all other variants. Changes made in the base class will affect the builds of both the base and big variants.
- A first simple example, installing the ffmpeg package package
In this example we will extend the min environment recipe of Debian 11. To do so, we use the kameleon new command as follows:
|
|
node ~/my_recipes:
|
kameleon new debian11_custom grid5000/debian11-min.yaml |
This creates the ~/my_recipes/debian11_custom.yaml file which is our new recipe. Besides, kameleon took care of importing in the directory all the files for the new recipe depends on.
You can list the recipes which are present in your workspace using the list command:
|
|
node ~/my_recipes:
|
kameleon list |
You can see your new debian11_custom recipe along with the recipes that it extends directly or indirectly.
You can look at the steps involved in the build of the recipes using the kameleon build --dryrun command:
|
|
node ~/my_recipes:
|
kameleon build --dryrun debian11_custom |
We see that the setup section has setup and run steps for an orchestrator: what's the part that prepares everything to use Puppet in the recipe and run it.
Since we want to write our customization with the Puppet language, we do not have to modify the debian11_custom.yaml recipe file much. We may just change the environment description by editing the recipe file ~/my_recipes/debian11_custom.yaml, and changing the description field starting at line 4, for instance:
#============================================================================== # # DESCRIPTION: My Grid'5000 Debian Bullseye # #==============================================================================
Once done, we can close the file and look at the Puppet code.
Puppet is a software configuration management tool that includes its own declarative language to describe system configuration. It is a model-driven solution that requires limited programming knowledge to use.
The puppets modules used by the Grid'5000 reference environments are located in ~/my_recipes/grid5000/steps/data/setup/puppet/modules/env/manifests/.
For our use case, we can look at the commonpackages.pp file. This is a really simple file that requests packages to be installed.
We can install ffmpeg like this :
class env::commonpackages{
}
...
class env::commonpackages::ffmpeg{
package{ 'ffmpeg':
ensure => installed;
}
}
...
In this quite simple use case, but if you have a package like postfix which requires more configuration, it could be more complex! You may look at the puppet classes to find out how it works. Puppet covers a lot of needs that we cannot describe in this documentation. To know more, please refer to the Puppet documentation.
- Second example, creating a new environment variant
For bigger changes, one may create a new environment variant. Having our own variant will allow keeping our set of customization separated from Grid'5000 recipes, which will ease maintenance (for example if Grid'5000 recipes are updated).
In this example, we want to install apache2 in the image. We have to create a user (www-data), add an apache2 configuration file, add the web application (here a simple html file), and ensure the service apache2 is running and enabled (starts at boot time). Therefore, we will extend the base variant of environment with modifications listed before.
First, we create a new Kameleon recipe named debian11-webserv, based on debian11-common:
|
|
localhost:
|
kameleon new debian11-webserv grid5000/debian11-common.yaml |
Then we create a new Puppet module apache2:
|
|
localhost:
|
mkdir grid5000/steps/data/setup/puppet/modules/apache2 |
|
|
localhost:
|
mkdir grid5000/steps/data/setup/puppet/modules/apache2/manifests |
|
|
localhost:
|
mkdir grid5000/steps/data/setup/puppet/modules/apache2/files |
Here is an example of content for grid5000/steps/data/setup/puppet/modules/apache2/manifests/init.pp:
# Module apache2
class apache2 ( ) {
package {
"apache2":
ensure => installed;
}
user {
"www-data":
ensure => present;
}
file {
"/var/www/my_application":
ensure => directory,
owner => www-data,
group => www-data,
mode => '0644';
"/var/www/my_application/index.html":
ensure => file,
owner => www-data,
group => www-data,
mode => '0644',
source => 'puppet:///modules/apache2/index.html',
require => File['/var/www/my_application'];
"/etc/apache2/sites-available/my_application.conf":
ensure => file,
owner => root,
group => root,
mode => '0644',
source => 'puppet:///modules/apache2/my_application.conf',
require => Package['apache2'];
"/etc/apache2/sites-enabled/my_application.conf":
ensure => link,
target => '../sites-available/my_application.conf',
require => Package['apache2'],
notify => Service['apache2'];
}
service {
"apache2":
ensure => running,
enable => true,
require => Package['apache2'];
}
}
Files my_application.conf and index.html must be stored in grid5000/steps/data/setup/puppet/modules/apache2/files/
grid5000/steps/data/setup/puppet/modules/apache2/files/my_application.conf:
<VirtualHost *:80>
ServerName my_application
DocumentRoot /var/www/my_application
ErrorLog /var/log/apache2/error.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog /var/log/apache2/access.log combined
</VirtualHost>
grid5000/steps/data/setup/puppet/modules/apache2/files/index.html:
<html>
<head>
<title>Hello World!</title>
</head>
<body>
<P>I <3 Grid'5000!</P>
</body>
</html>
We will now integrate this module in a new variant called webserv that extends the base variant.
First we must create a file grid5000/steps/data/setup/puppet/modules/env/manifests/webserv.pp:
# This file contains the apache2 class used to configure a user environment based on base variant, that contains apache2.
class env::webserv ( ) {
class { "env::base": } # we include base variant here without overloading any of it's default parameters
class { "apache2": }
}
To have it included by the actual Puppet setup, we must also create grid5000/steps/data/setup/puppet/manifests/webserv.pp:
# User env containing apache2
# All recipes are stored in env module. Here called with webserv variant parameter.
class { 'env':
given_variant => 'webserv';
}
And finally, modify grid5000/steps/data/setup/puppet/modules/env/manifests/init.pp to include your variant:
case $variant {
'min' : { include env::min }
'base': { include env::base }
'webserv': { include env::webserv }
'nfs' : { include env::nfs }
'prod': { include env::prod }
'big' : { include env::big }
default: { notify {"flavor $variant is not implemented":}}
}
Then, instruct in the debian11-webserv recipe to build our webserv variant by modifying the variant variable of the global section of the recipe.
We edit debian11-webserv.yaml as follows:
---
extend: grid5000/debian11-common.yaml
global:
# You can see the base template `grid5000/debian11-common.yaml` to know the
# variables that you can override
variant: webserv
bootstrap:
- "@base"
setup:
- "@base"
export:
- "@base"
Working with a Grid'5000 reference environment recipe without using Puppet
All Grid'5000 reference environments can also be extended to add modifications using only the kameleon language (not Puppet).
Let's say we want to extend grid5000/debiantesting-min. We run the following command:
|
|
node ~/my_recipes:
|
kameleon new my_custom_environment grid5000/debiantesting-min |
This creates the ~/my_recipes/my_custom_environment.yaml file, which this time directly describes that it extends grid5000/debiantesting-min.
We can now edit the recipe file, our customizations of the environment operating system is to be written in the setup section (bootstrap and export should not require any changes as long as we work on customizing the environment for Grid'5000).
For example, just like in the previous section with Puppet, we describe below how to install the ffmpeg package (but in the kameleon language this time).
We add a new step to the recipe, which is just a sequence of actions to execute. This basically gives a setup section in our recipe as follows:
setup:
- "@base"
- install_more_packages:
- install_ffmpeg:
- exec_in : apt-get update && apt-get install -y ffmpeg
"@base"means that the steps from the environment we extend should be executed among our new steps (a bit like when using super() in a constructor of a class in Java or Ruby to call the constructor of the inherited class). Mind that some operations will be performed in your back (mind inspecting what the recipe actually does, e.g. with kameleon build --dryrun)exec_inmeans that the command will be executed with bash in the VM of the build process. See the kameleon documation for other commands.install_more_packagesis a macrostep,install_ffmpegis a microstep: It is mandatory to define the 2 level of steps and respect the format of a correct YAML document.
Please notice that this is very similar to what we did when extending the grid5000/from_grid5000_environment/base recipe, but the @base is added, since we want the setup section of the extended recipe to be executed.
Again, to inspect our environment before launching the build:
- We can look at the information about the environment with
kameleon info:
|
|
node ~/my_recipes:
|
kameleon info my_custom_environment |
- We can look at what the build of the environment involves by running
kameleon build --dryrun:
|
|
node ~/my_recipes:
|
kameleon build --dryrun my_custom_environment |
If any error is raised with those commands, it probably come from a bad syntax in the recipe (e.g. bad YAML formating).
Build and test
Once the recipe is written, we can launch the build. To do so, we just have to run following command:
|
|
node ~/my_recipes:
|
kameleon build my_custom_environment |
We end up with a build directory that contains the freshly build files we are interested in:
- File
build/my_custom_environment/my_custom_environment.dsc
- This is the description file of the new environment (this is a YAML file, the file extension does not really matter, be it
.dsc,.envor.yaml) - It can be used either directly with kadeploy to run the deployment without registering the environment:
After creating a new job of type deploy, we run the following kadeploy command from the frontend:
|
|
frontend:
|
kadeploy -a ~/my_recipe/build/my_custom_environment/my_custom_environment.dsc |
- Or to register the environment with
kaenv3, for later use with kadeploy.
|
|
frontend:
|
kaenv3 -a ~/my_recipe/build/my_custom_environment/my_custom_environment.dsc |
- File
build/my_custom_environment/my_custom_environment.tar.zst
- This is the tarball of our new environment, referred to in the environment description
- File
build/my_custom_environment/my_custom_environment.qcow2
- It is a qcow2 version of the environment for use with
qemu(as seen earlier, it is not built when extendinggrid5000/from_grid5000_environment/base).
Just run Qemu on the image:
|
|
node:
|
qemu-system-x86_64 -enable-kvm -m 2048 -cpu host ~/my_recipe/build/my_custom_environment/my_custom_environment.qcow2 |
Creating an environment for an unsupported Operating System
If an Operating System is not provided as a Grid'5000 environment already, it should be doable to write a kameleon recipe to build it, assuming it can:
- boot the OS installer in a VM and do an unattended installation
- run some additional setup
- finally export the built system ready to be consumed by
kadeploy3.
Please get in touch with the Grid'50000 technical team to explain your motivation and ideas and possibly to get some help.
|
|
Warning |
|---|---|
This task requires strong system administrator skills and a very good understanding of how the Grid'5000 bare metal deployment functions. | |