mirror of
https://github.com/clearlinux/clear-linux-documentation.git
synced 2026-09-06 05:41:44 +00:00
Merge branch 'master' of clrgitlab.intel.com:clr-documentation/project-docs
This commit is contained in:
Leona
@@ -3,15 +3,34 @@
|
||||
Bulk Provisioning
|
||||
=================
|
||||
|
||||
In the data center new machines are often landed in large groups. When dealing with large amounts of new hardware, data center admins need a way to install and configure these machines with a minimal amount of effort. In support of this use case the Clear Linux team has developed some tooling and instructions on how to bulk-load machines with Clear Linux using iPXE.
|
||||
Data centers tend to land and install new machines in bulk. When dealing with
|
||||
large quantities of new machines or hardware upgrades, data center admins may need
|
||||
a way to install and configure with a minimal amount of effort. To support this
|
||||
use case, the Clear Linux team has developed some tooling and instructions for
|
||||
how to bulk-load machines with Clear Linux using iPXE.
|
||||
|
||||
This bulk provisioning scenario is a variation on the Network Booting and installation scenario with some alterations to facillitate installing and configuring many hosts. The Clear Linux installer (Ister) was augmented to detect and find cloud-init configuration data during the install. If this data is found a cloud-init file is fetched and the host, after being rebooted by ister, uses micro config drive (ucf) to configure the host as directed by the cloud-init configuration file.
|
||||
This bulk provisioning scenario is a variation on the :ref:`network_boot` scenario,
|
||||
with some alterations to facilitate installing and configuring many hosts. The Clear
|
||||
Linux installer (``Ister``) was augmented to detect and find ``cloud-init`` configuration
|
||||
data during the install. When this data is found, a :file:`cloud-init` file is fetched,
|
||||
and the host, after being rebooted by ``ister``, uses micro-config drive (``ucf``) to
|
||||
configure the host as directed by the :file:`cloud-init` configuration file.
|
||||
|
||||
In our pilot of this workflow we used clear-cloud-init (which in the future will become ucf - micro config drive) to install the trust relationships for the host to be further managed by Ansible. The cloud-init configuration file was served by a simple little web-application that Ister knows how to query for host configuration data. This allowed us to power on one hundered machines, each of which picked up the Clear Linux installer via PXE, installed Clear Linux, rebooted, and came up ready to be managed through Ansible.
|
||||
In our pilot of this workflow, we used ``clear-cloud-init`` (which will become ucf - micro config drive)
|
||||
to install the trust relationships for the host to be further managed by Ansible. The
|
||||
:file:`cloud-init` configuration file was served by a simple little web application
|
||||
that ``Ister`` knows how to query for host configuration data. This allowed us to
|
||||
simultaneously power-on one hundred machines, each of which
|
||||
* picked up the Clear Linux installer via PXE,
|
||||
* installed Clear Linux,
|
||||
* rebooted, and
|
||||
* entered into a mode that can be managed through Ansible.
|
||||
|
||||
The web application that serves cloud-init configurations to Ister is uninspiringly named "Ister Cloud Init Service" (ICIS), and is available at github - https://github.com/clearlinux/ister-cloud-init-svc
|
||||
The web application that serves cloud-init configurations to ``Ister`` is uninspiringly named
|
||||
"Ister Cloud Init Service" (ICIS), and is available at github - https://github.com/clearlinux/ister-cloud-init-svc
|
||||
|
||||
One nice attribute of this system is that once the iPXE bits are created many installer behaviors can be configured without having to regenerate the iPXE bits.
|
||||
One nice attribute of this system is that once the iPXE bits are created, many installer
|
||||
behaviors can be configured without having to regenerate the iPXE bits.
|
||||
|
||||
System Architecture
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
@@ -22,9 +41,13 @@ The following diagrams illustrate the system architecture.
|
||||
:align: center
|
||||
:alt: pxe-server-overview
|
||||
|
||||
As can be seen, ICIS is a web application (specifically a Flask application, hence managed by uwsgi under nginx) that can really run anywhere visible to hosts booting from PXE. In our example we simply hosted it on the same system serving the pxe content.
|
||||
As can be seen, ICIS is a web application (specifically a Flask application, hence managed by ``uwsgi``
|
||||
under nginx) that can run **anywhere** visible to hosts booting from PXE. In our example, we simply
|
||||
hosted it on the same system serving the pxe content.
|
||||
|
||||
The following diagram illustrates the flow of information between the pxe server and a host booting into the installer via pxe. This diagram is intended to show the logical flow of information, and is not a literal depiction of the protocol-level exchanges.
|
||||
The following diagram illustrates the flow of information between the pxe server and a host booting
|
||||
into the installer via pxe. This diagram is intended to show the logical flow of information, and
|
||||
is not a literal depiction of the protocol-level exchanges.
|
||||
|
||||
.. image:: _static/images/icis_installer_workflow.png
|
||||
:align: center
|
||||
@@ -33,36 +56,57 @@ The following diagram illustrates the flow of information between the pxe server
|
||||
Configuration Overview
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Here is a high-level overview describing setting up and configuring a bulk provisioning solution.
|
||||
Here is a high-level overview describing set up and configuration of a bulk-provisioning solution.
|
||||
|
||||
* First, stand up an iPXE server as described in the :doc:`network boot <network_boot>` docs. Note that you will be generating your own artifacts to be served by PXE in a later step.
|
||||
* First, stand up an iPXE server as described in the :ref:`network_boot` docs. Note that you will
|
||||
be generating your own artifacts to be served by PXE in a later step.
|
||||
|
||||
* Land `Ister Cloud Init Service <https://github.com/clearlinux/ister-cloud-init-svc>`_ on the pxe server. The README in the ICIS github repo has directions on how to install and configure.
|
||||
* Land `Ister Cloud Init Service <https://github.com/clearlinux/ister-cloud-init-svc>`_ on the
|
||||
pxe server. The README in the ICIS github repo has directions on how to install and configure.
|
||||
|
||||
* Generate the installer that will load and boot over PXE. Copy the relevant files into the appropriate location on the iPXE server.
|
||||
* Generate the installer that will load and boot over PXE. Copy the relevant files into the
|
||||
appropriate location on the iPXE server.
|
||||
|
||||
A pxe installer is generated for every release of Clear Linux OS. It can be found alongside the published images in https://download.clearlinux.org/releases/XXXXX/clear/clear-XXXXX-pxe.tar.xz
|
||||
A pxe installer is generated for every release of Clear Linux OS. It can be found alongside the
|
||||
published images in https://download.clearlinux.org/releases/XXXXX/clear/clear-XXXXX-pxe.tar.xz
|
||||
|
||||
Alternatively use the `create_pxe.sh <https://github.com/bryteise/ister/blob/master/create_pxe.sh>`_ script to roll your own. Note this creates the pxe-installer from the "provision" installer in Clear Linux which is a touchless installer that takes all installation information from a config file. You can get this image from a given Clear Linux release by looking in https://download.clearlinux.org/releases/XXXX/clear/ where XXXX is a Clear Linux release number. Just download the image alongside the create_pxe.sh script and name it provision.img.
|
||||
Alternatively, use the `create_pxe.sh <https://github.com/bryteise/ister/blob/master/create_pxe.sh>`_
|
||||
script to roll your own. Note this creates the pxe-installer from the "provisioning" installer in
|
||||
Clear Linux. This is a touchless installer that takes all installation information from a config
|
||||
file. You can get this image from a given Clear Linux release by looking
|
||||
in https://download.clearlinux.org/releases/XXXX/clear/ where XXXX is a Clear Linux release number.
|
||||
Just download the image alongside the ``create_pxe.sh`` script and name it ``provision.img``.
|
||||
|
||||
* Stage config files for ister that will govern Ister's behavior. This includes modifying the ipxe boot script to pass an additional parameter to the kernel.
|
||||
* Stage config files for ``ister`` that will govern Ister's behavior. This includes modifying the
|
||||
script for ipxe boot, getting it to pass an additional parameter to the kernel.
|
||||
|
||||
The magic that ties all of this together is that the pxe script conveys to ister the location of its configuration files via the kernel command line of the installer it kicks off. The kernel preserves its command line precisely, and ister inspects it via /proc/cmdline.
|
||||
The magic that ties all of this together is that the pxe script conveys to ister the location of its configuration files via the kernel command line of the installer it kicks off. The kernel preserves its command line precisely, and ister inspects it via ``/proc/cmdline``.
|
||||
|
||||
Here is an example pxe script:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
#!ipxe
|
||||
kernel linux quiet rdinit=/usr/lib/systemd/systemd-bootchart initcall_debug tsc=reliable no_timer_check noreplace-smp rw initrd=initrd isterconf=http://192.168.1.1/static/ister/ister.conf
|
||||
kernel linux quiet rdinit=/usr/lib/systemd/systemd-bootchart initcall_debug tsc=reliable
|
||||
no_timer_check noreplace-smp rw initrd=initrd isterconf=http://192.168.1.1/static/ister/ister.conf
|
||||
initrd initrd
|
||||
boot
|
||||
|
||||
When the pxe installer kicks off ister it will notice location of its conf file was given on the kernel command line and fetch the file. This file in turn tells ister where to get the json template file that describes partition schemes, and which version of Clear Linux to install. This means that so long as the contents of a release are compatible with the version of software update (swupd) in the installer, this pxe installer can be told to install a newer version of Clear Linux simply by tweaking the json on the web server instead of rolling an entire new installer.
|
||||
When the pxe installer kicks off ``ister``, it will make note of the location of the ``conf`` file
|
||||
that was given on the kernel command line, and fetch the file. This file then tells ``ister`` where
|
||||
to get the json template file that describes partition schemes, and which version of Clear Linux to
|
||||
install. This means that so long as the contents of a release are compatible with the version of
|
||||
software update (``swupd``) in the installer, this pxe installer can be told to install a newer
|
||||
version of Clear Linux simply by tweaking the json on the web server, rather than rolling an
|
||||
entirely new installer.
|
||||
|
||||
One other important piece of configuration data in the json configuration file is the location of an ICIS configuration service. Ister will query ICIS for a role using the MAC address of the network interface being used to communicate with the ICIS service. Ister will then fetch that specific cloud-init file and configure ucd to run on first-boot against that config file.
|
||||
One other important piece of configuration data in the json configuration file is the location of
|
||||
an ICIS configuration service. Ister will query ICIS for a role using the MAC address of the network
|
||||
interface being used to communicate with the ICIS service. Ister will then fetch that specific
|
||||
:file:`cloud-init` file and ``configure ucd`` to run on first-boot against that config file.
|
||||
|
||||
The `Ister Cloud Init Service <https://github.com/clearlinux/ister-cloud-init-svc>`_ github repo has example ister configuration files under ``static/ister``.
|
||||
The `Ister Cloud Init Service <https://github.com/clearlinux/ister-cloud-init-svc>`_ github repo
|
||||
has example ister configuration files under ``static/ister``.
|
||||
|
||||
Here is an example ister-template.json file.
|
||||
|
||||
@@ -87,7 +131,9 @@ Here is a high-level overview describing setting up and configuring a bulk provi
|
||||
"IsterCloudInitSvc": ["http://192.168.1.1/"]
|
||||
}
|
||||
|
||||
* Configure ICIS to map MAC addresses to role files appropriately. Then create the role files, which are cloud-init configuration files. Note, it is possible to simply specify a "default" role for any unmatched MAC address, which is handy if all install targets are to be configured identically.
|
||||
* Configure ICIS to map MAC addresses to role files appropriately. Then create the role files, which
|
||||
are ``cloud-init`` configuration files. Note, it is possible to simply specify a "default" role for
|
||||
any unmatched MAC address; this may be handy when all install targets are to be configured identically.
|
||||
|
||||
* Final pre-flight check. Assuming your iPXE server is at 192.168.1.1, all of the following urls need to be working.
|
||||
|
||||
|
||||
@@ -0,0 +1,12 @@
|
||||
.. _ciao-cluster-setup-quick:
|
||||
|
||||
Easy ciao development cluster setup
|
||||
###################################
|
||||
|
||||
For quick ciao development cluster setup, see:
|
||||
|
||||
https://github.com/01org/ciao/wiki/Single-Machine-Development-Environment
|
||||
|
||||
For more detailed and configurable manual setup of ciao, see:
|
||||
|
||||
https://clearlinux.org/documentation/ciao-cluster-setup.html
|
||||
@@ -2,8 +2,8 @@
|
||||
|
||||
.. contents::
|
||||
|
||||
ciao cluster setup
|
||||
##################
|
||||
Detailed manual ciao cluster setup
|
||||
##################################
|
||||
|
||||
This topic explains how to set up a cluster of machines running Clear Linux* OS
|
||||
for Intel® Architecture with :abbr:`Cloud Integrated Advanced Orchestrator (CIAO)`, or ciao.
|
||||
@@ -71,10 +71,10 @@ Install Clear Linux OS for Intel Architecture as host on all nodes
|
||||
|
||||
Install Clear Linux OS for Intel Architecture as the host
|
||||
OS on all nodes by following the instructions in the topic
|
||||
:ref:`gs_installing_clr_as_host`. The current April 2016
|
||||
`downloadable installer images`_ are compatible with ciao.
|
||||
:ref:`gs_installing_clr_as_host`. The current `downloadable installer images`_
|
||||
are compatible with ciao.
|
||||
|
||||
After the base installation on each node add the following additional
|
||||
After the base installation on each node, add the following additional
|
||||
bundle, which adds components needed by CIAO::
|
||||
|
||||
$ swupd bundle-add cloud-control
|
||||
@@ -85,7 +85,7 @@ Build the CIAO software
|
||||
-----------------------
|
||||
|
||||
Ciao is written in the Go programming language. It requires Go 1.6 to
|
||||
build. Most Linux distributions have out of date versions of Go in their
|
||||
build. Most Linux distributions have out-of-date versions of Go in their
|
||||
repositories, so you will probably need to download and install a recent
|
||||
version of Go. This can be easily done by following the
|
||||
`Go installation instructions <https://golang.org/doc/install>`__.
|
||||
@@ -146,7 +146,7 @@ the `Starting a workload` section.
|
||||
Keystone node
|
||||
-------------
|
||||
|
||||
You need to run a Keystone service. General documentation on setting
|
||||
You need to run a Keystone service. General documentation on setting
|
||||
up Keystone services can be found at the `OpenStack developer`_ website.
|
||||
We need a few configuration points. For example:::
|
||||
|
||||
@@ -157,7 +157,7 @@ We need a few configuration points. For example:::
|
||||
$ openstack role add --project demo --user demo user
|
||||
|
||||
This adds a ciao compute service, a keystone user and project for the
|
||||
controller (a.k.a. csr) node, and a demo user with the password
|
||||
controller (a.k.a. ``csr``) node, and a demo user with the password
|
||||
``giveciaoatry``.
|
||||
|
||||
Controller node setup
|
||||
@@ -441,11 +441,16 @@ described above.
|
||||
Access your workload
|
||||
====================
|
||||
|
||||
Once your workload is up, you need to know it's IP address and assigned port, you can find it via ciao-cli::
|
||||
Once your workload is up, you need to know its IP address and assigned
|
||||
port, you can find it via ciao-cli::
|
||||
|
||||
$ ciao-cli instance list
|
||||
|
||||
Then look for the column "SSH IP", there is the IP assigned to your workload, next to it, you will see the column SSH PORT, that's the port that you will use to access a specific workload using your private key defined in the cloud-init configuration and the user "demouser"::
|
||||
Then look for the column "SSH IP", there is the IP assigned to your
|
||||
workload, next to it, you will see the column SSH PORT; that's the
|
||||
port that you will use to access a specific workload using your
|
||||
private key defined in the cloud-init configuration and the demo
|
||||
user name ``demouser``::
|
||||
|
||||
$ ssh -p <workload_port> -i </path/to/your/private-key> demouser@<workload-ip>
|
||||
|
||||
@@ -462,7 +467,7 @@ On your scheduler node, run the following command::
|
||||
|
||||
$ sudo killall -w -9 qemu-system-x86_64
|
||||
|
||||
On your controller node, go to the directory in which you ran the
|
||||
On your controller node, go to the directory where you ran the
|
||||
ciao-controller binary and run the following commands::
|
||||
|
||||
$ sudo killall -w -9 ciao-controller
|
||||
@@ -503,9 +508,9 @@ For general debugging, you can:
|
||||
binaries' command lines.
|
||||
* Reduce your tenants to one (specifically the one with no limits).
|
||||
* Launch fewer VMs in a herd. A small Intel NUC with 16GB of RAM can handle as many as
|
||||
50-100 2vcpu 218MB RAM VMs starting at once per compute node. Larger dual socket
|
||||
many thread CPU with hundreds of GB RAM Haswell-EP servers can handle as many as 500
|
||||
such VMs starting at once per compute node.
|
||||
50-100 2vcpu 218MB RAM VMs starting at once per compute node. Larger dual-socket
|
||||
many threaded CPUs with hundreds of GB RAM Haswell-EP servers can handle as many as
|
||||
500 such VMs starting at once per compute node.
|
||||
* Tweak the launcher to enable remote access: go get with ``--tags=debug`` to enable
|
||||
a netcat based console redirection for each VM. The launcher console verbose output
|
||||
will indicate per VM how to connect to the console. For example::
|
||||
|
||||
+64
-115
@@ -5,173 +5,118 @@
|
||||
Deploying ciao via automation
|
||||
#############################
|
||||
|
||||
Cloud Integrated Advanced Orchestrator (``ciao``) is a new workload
|
||||
scheduler designed to address limitations of current cloud OS projects.
|
||||
CIAO provides a lightweight, fully TLS-based minimal config, is
|
||||
workload-agnostic, easy to update, offers an optimized-for-speed
|
||||
Cloud Integrated Advanced Orchestrator (``ciao``) is a new workload
|
||||
scheduler designed to address limitations of current cloud OS projects.
|
||||
Ciao provides a lightweight, fully TLS-based minimal config, is
|
||||
workload-agnostic, easy to update, offers an optimized-for-speed
|
||||
scheduler, and is currently optimized for OpenStack*.
|
||||
|
||||
For more information, see https://clearlinux.org/ciao.
|
||||
|
||||
|
||||
Environment
|
||||
===========
|
||||
|
||||
For this example, we'll use a total of four nodes:
|
||||
For this example, we'll use a total of five nodes:
|
||||
- A deployment machine which will be used to run the playbooks.
|
||||
- A `controller`_ node which will be used to communicate with Keystone.
|
||||
- Two `compute nodes`_, which will spawn the VMs and containers.
|
||||
- A `network node`_ which will handle the networking for the workloads.
|
||||
|
||||
Note: The deployment machine is not a necessary part of the cluster; it could be
|
||||
the sysadmin's computer or a CI/CD server.
|
||||
|
||||
.. _prerequisites:
|
||||
|
||||
Prerequisites
|
||||
=============
|
||||
Ansible* uses :command:`ssh` to run commands on the remote nodes. In order to do
|
||||
that, the nodes must be configured to allow passwordless ssh connections
|
||||
from the root user. Follow these steps to configure your nodes.
|
||||
|
||||
#. Generate ssh keys:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# ssh-keygen
|
||||
|
||||
#. Enable root login:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# echo "PermitRootLogin yes" >> /etc/ssh/sshd_config
|
||||
|
||||
#. Enable sshd service:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# systemctl enable sshd
|
||||
# systemctl start sshd
|
||||
|
||||
#. Allow passwordless login:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# ssh-copy-id -i <ssh_key> root@node
|
||||
Ansible* uses :command:`ssh` to run commands on the remote nodes. In order to do
|
||||
that, the nodes must be configured to allow passwordless SSH connections
|
||||
from the deployment machine to the cluster nodes. The user should also have
|
||||
sudo privileges on the cluster nodes.
|
||||
|
||||
|
||||
Install the software
|
||||
====================
|
||||
|
||||
Install the ``sysadmin-hostmgmt`` bundle on the development node. This
|
||||
bundle contains the Ansible software required to run the playbooks, as
|
||||
well as some Ansible roles and sample playbooks that you can use to
|
||||
build your own:
|
||||
In Clear Linux, install the ``sysadmin-hostmgmt`` bundle on the deployment node. This
|
||||
bundle contains the Ansible software required to run the playbooks.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# swupd bundle-add sysadmin-hostmgmt
|
||||
|
||||
Install ``go-basic``, ``os-core-dev``, ``kvm-host`` and ``os-common`` bundles
|
||||
on the development node. These bundles contain requirements needed by the playbooks.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# swupd bundle-add go-basic os-core-dev kvm-host os-common
|
||||
|
||||
go-basic
|
||||
provides golang, which is needed to compile ciao
|
||||
os-core-dev
|
||||
provides gcc, which is needed to compile some ciao dependencies
|
||||
kvm-host
|
||||
provides qemu, which is needed to build the CNCI image
|
||||
os-common
|
||||
provides python-keystone client, which is a dependency of the keystone role
|
||||
|
||||
For Ubuntu and Fedora, follow the instructions from `github`_
|
||||
|
||||
Create the playbook
|
||||
===================
|
||||
|
||||
The ``sysadmin-hostmgmt`` bundle includes some sample playbooks that
|
||||
you may use and customize for your own needs. Start by making a copy
|
||||
The ``sysadmin-hostmgmt`` bundle includes some sample playbooks that
|
||||
you may use and customize for your own needs. Start by making a copy
|
||||
of the sample playbook into your home folder
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# cp -r /usr/share/ansible/examples/ciao ~/
|
||||
|
||||
The playbook consists of three files that you should modify to fit
|
||||
your needs::
|
||||
Note: These files are also hosted in `github`_
|
||||
|
||||
ciao/
|
||||
|-- ciao.yml
|
||||
|-- group_vars
|
||||
| -- all
|
||||
+-- hosts
|
||||
The relevant files in the playbook are the following:
|
||||
|
||||
The :file:`hosts` file contains the IP addresses/hostnames of your
|
||||
nodes, grouped under the roles they will serve. For this example
|
||||
it should look like this::
|
||||
* The `ciao.yml`_ file is the master playbook file and includes a playbook
|
||||
for each component of the cluster.
|
||||
|
||||
[dbservers]
|
||||
ciao-controller.example.com
|
||||
|
||||
[openstack_identity]
|
||||
ciao-controller.example.com
|
||||
|
||||
[openstack_image]
|
||||
ciao-controller.example.com
|
||||
|
||||
[ciao_controller]
|
||||
ciao-controller.example.com
|
||||
|
||||
[ciao_network]
|
||||
ciao-network.example.com
|
||||
|
||||
[ciao_compute]
|
||||
ciao-compute1.example.com
|
||||
ciao-compute2.example.com
|
||||
* The `hosts`_ file is the hosts inventory file and contains the IP
|
||||
addresses/FQDN of your nodes, grouped under the roles they will serve
|
||||
|
||||
This ``groups_var/all`` file contains variables that will be applied
|
||||
to your ciao setup. The mandatory variables are already there; be
|
||||
sure to change the values accordingly to fit your environment. It
|
||||
should look something like this::
|
||||
* The `groups_vars/all`_ file contains variables that will be applied
|
||||
to your ciao setup. The mandatory variables are already there; be
|
||||
sure to change the values accordingly to fit your environment
|
||||
|
||||
---
|
||||
# Vars required for mariadb and os-common
|
||||
# https://github.com/clearlinux/clear-config-management/tree/master/roles/mariadb
|
||||
# https://github.com/clearlinux/clear-config-management/tree/master/roles/os-common
|
||||
database_root_password: secret
|
||||
|
||||
# Vars required for os-common
|
||||
# https://github.com/clearlinux/clear-config-management/tree/master/roles/os-common
|
||||
keystone_fqdn: ciao-controller.example.com
|
||||
keystone_admin_password: secret
|
||||
|
||||
# Vars required for os-keystone
|
||||
# https://github.com/clearlinux/clear-config-management/tree/master/roles/os-keystone
|
||||
keystone_database_password: secret
|
||||
keystone_root_domain: example.com
|
||||
keystone_p12password: secret
|
||||
|
||||
# Vars required for ciao-common
|
||||
# https://github.com/clearlinux/clear-config-management/tree/master/roles/ciao-common
|
||||
ciao_controller_fqdn: ciao-controller.example.com
|
||||
|
||||
# Vars required for ciao-controller
|
||||
# https://github.com/clearlinux/clear-config-management/tree/master/roles/ciao-controller
|
||||
ciao_service_user: csr
|
||||
ciao_service_password: secret
|
||||
ciao_admin_email: admin@example.com
|
||||
ciao_cert_organization: Example, Inc.
|
||||
ciao_guest_user: demouser
|
||||
ciao_guest_key: ~/.ssh/guest_vms.pub
|
||||
|
||||
* The ``ciao_guest_key`` value in :file:`groups_var/all` is the key to be used to connect to the VMs created by
|
||||
ciao; you can use the ``ssh-keygen`` command to create one.
|
||||
|
||||
The ``ciao_guest_key`` is the key to be used to connect to the VMs created by
|
||||
ciao; you can use the ``ssh-keygen`` command to create one as explained in the
|
||||
:ref:`prerequisites` section.
|
||||
|
||||
A full list of available variables can be found in the ciao-* roles at
|
||||
A full list of available variables can be found in the :file:`defaults/main.yml` file of each role at
|
||||
https://github.com/clearlinux/clear-config-management/tree/master/roles
|
||||
|
||||
Install the required ansible-roles
|
||||
==================================
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# ansible-galaxy install -r requirements.yml
|
||||
|
||||
|
||||
Run the playbook
|
||||
================
|
||||
Once you have your variables and hosts file configured, the deployment can
|
||||
be fired with the following command:
|
||||
Once you have your variables and hosts file configured, the deployment can
|
||||
be started with the following command:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# ansible-playbook -i hosts ciao.yml --private-key=<ssh_key>
|
||||
|
||||
$ ansible-playbook -i hosts ciao.yml --private-key=<ssh_key>
|
||||
|
||||
|
||||
Verify
|
||||
======
|
||||
After ansible is done with the setup, you can verify the cluster is ready
|
||||
by running the following command on the controller node. Change the **username**,
|
||||
**password**, **controller**, and **identity** values to match your setup, as
|
||||
by running the following command on the controller node. Change the **username**,
|
||||
**password**, **controller**, and **identity** values to match your setup, as
|
||||
was specified in the ``groups_var/all`` file:
|
||||
|
||||
.. code-block:: console
|
||||
@@ -183,8 +128,8 @@ was specified in the ``groups_var/all`` file:
|
||||
Offline 0
|
||||
Maintenance 0
|
||||
|
||||
You could also take a look at the :file:`~/ciaorc` file that contains the
|
||||
following environment variables:
|
||||
You could also take a look at the :file:`./ciaorc` file created on your
|
||||
deployment node, which contains the following environment variables:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@@ -209,3 +154,7 @@ then you could verify with the following command:
|
||||
.. _controller: https://github.com/01org/ciao/tree/master/ciao-controller
|
||||
.. _compute nodes: https://github.com/01org/ciao/tree/master/ciao-launcher
|
||||
.. _network node: https://github.com/01org/ciao/tree/master/ciao-launcher
|
||||
.. _ciao.yml: https://github.com/clearlinux/clear-config-management/blob/master/examples/ciao/ciao.yml
|
||||
.. _hosts: https://github.com/clearlinux/clear-config-management/blob/master/examples/ciao/hosts
|
||||
.. _groups_vars/all: https://github.com/clearlinux/clear-config-management/blob/master/examples/ciao/group_vars/all
|
||||
.. _github: https://github.com/clearlinux/clear-config-management/tree/master/examples/ciao
|
||||
|
||||
@@ -6,6 +6,7 @@ Tutorials
|
||||
|
||||
gs-clear-containers-getting-started
|
||||
ciao-deploy
|
||||
ciao-cluster-setup-quick.rst
|
||||
ciao-cluster-setup
|
||||
|
||||
|
||||
|
||||
@@ -1,13 +1,14 @@
|
||||
Advanced configuration
|
||||
######################
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
clear-containers
|
||||
network_boot
|
||||
mixer
|
||||
ac-dpdk
|
||||
ac-ovs-dpdk
|
||||
validate_sigs
|
||||
|
||||
Advanced configuration
|
||||
######################
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
clear-containers
|
||||
network_boot
|
||||
bulk_provisioning
|
||||
mixer
|
||||
ac-dpdk
|
||||
ac-ovs-dpdk
|
||||
validate_sigs
|
||||
|
||||
|
||||
Reference in New Issue
Block a user