add docusaurus docs
This commit is contained in:
20
docs/.gitignore
vendored
Normal file
20
docs/.gitignore
vendored
Normal file
@@ -0,0 +1,20 @@
|
||||
# Dependencies
|
||||
/node_modules
|
||||
|
||||
# Production
|
||||
/build
|
||||
|
||||
# Generated files
|
||||
.docusaurus
|
||||
.cache-loader
|
||||
|
||||
# Misc
|
||||
.DS_Store
|
||||
.env.local
|
||||
.env.development.local
|
||||
.env.test.local
|
||||
.env.production.local
|
||||
|
||||
npm-debug.log*
|
||||
yarn-debug.log*
|
||||
yarn-error.log*
|
||||
33
docs/README.md
Normal file
33
docs/README.md
Normal file
@@ -0,0 +1,33 @@
|
||||
# Website
|
||||
|
||||
This website is built using [Docusaurus 2](https://v2.docusaurus.io/), a modern static website generator.
|
||||
|
||||
## Installation
|
||||
|
||||
```console
|
||||
yarn install
|
||||
```
|
||||
|
||||
## Local Development
|
||||
|
||||
```console
|
||||
yarn start
|
||||
```
|
||||
|
||||
This command starts a local development server and open up a browser window. Most changes are reflected live without having to restart the server.
|
||||
|
||||
## Build
|
||||
|
||||
```console
|
||||
yarn build
|
||||
```
|
||||
|
||||
This command generates static content into the `build` directory and can be served using any static contents hosting service.
|
||||
|
||||
## Deployment
|
||||
|
||||
```console
|
||||
GIT_USER=<Your GitHub username> USE_SSH=true yarn deploy
|
||||
```
|
||||
|
||||
If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the `gh-pages` branch.
|
||||
3
docs/babel.config.js
Normal file
3
docs/babel.config.js
Normal file
@@ -0,0 +1,3 @@
|
||||
module.exports = {
|
||||
presets: [require.resolve('@docusaurus/core/lib/babel/preset')],
|
||||
};
|
||||
75
docs/docs/about/architecture.md
Normal file
75
docs/docs/about/architecture.md
Normal file
@@ -0,0 +1,75 @@
|
||||
---
|
||||
id: architecture
|
||||
title: Architecture
|
||||
---
|
||||
|
||||
Warewulf's primary design goal is to facilitate software installation, configuration and management on the most common architecture for an HPC cluster nowadays. This popular cluster design originated 25 years ago with the seminal commodity-off-the-shelf (COTS) architecture commonly known as the "Beowulf".
|
||||
|
||||
## The Beowulf
|
||||
|
||||
The original [Beowulf Cluster](https://en.wikipedia.org/wiki/Beowulf_cluster) was developed in 1996 by Dr. Thomas Sterling and Dr. Donald Becker at NASA. The architecture is defined as a group of similar compute worker nodes all connected together using standard commodity equipment on a private network segment. The control node is dual homed (has two network interface cards) with one of these network interface cards attached to the upstream network and the other connected to the same private network which connects the compute worker nodes (as seen in the figure below).
|
||||
|
||||
.. image:: /images/beowulf_architecture.png
|
||||
|
||||
This architecture is very advantageous for creating a scalable HPC cluster resource, but it is an overly simple portrayal of the cluster ecosystem. To this thumbnail sketch we must add storage, scheduling and resource management, monitoring, interactive systems, and as the system grows, it may need to have groups of nodes with different features, architectures, vintages, memory configurations, GPUs or interconnects. As the system grows more complex, the need for a scalable control surface also increases which can result in even more complexity.
|
||||
|
||||
## Provisioning
|
||||
|
||||
Warewulf is designed to support the simplest of clusters, but also the most complicated, largest, and specialized resources that are in demand today. But when implementing all the various configurations, we rely on the basic architecture illustrated above. We can rely on such a simple schematic because Warewulf is designed to "own" the network broadcast domain and manage how these worker nodes boot.
|
||||
|
||||
As mentioned before, Warewulf is designed first and foremost to be a stateless provisioning subsystem. This means that the worker nodes maintain no state about their configuration, operating system or purpose when they are powered off. So, when these systems boot, they retain no knowledge of who they are, what they are supposed to do or how they got there. For these reasons, the worker nodes will need to boot via [PXE](https://en.wikipedia.org/wiki/Preboot_Execution_Environment) in order to retrieve a personality and a purpose.
|
||||
|
||||
## PXE
|
||||
|
||||
Most servers will have network interface cards that support PXE by default. In a nutshell, PXE will allow the network card to be seen by the BIOS as a bootable device. This means that the boot order may need to be configured in the system's BIOS on the worker nodes to allow it to boot. If there is also another bootable device on these systems, it might be necessary to set the network interface card to boot first.
|
||||
|
||||
When the system boots via PXE, it will begin a chain reaction of events:
|
||||
|
||||
1. The network card will register an option ROM into the BIOS
|
||||
2. The BIOS will run through all of its functions and finish with boot devices
|
||||
3. The boot devices are attempted to be booted in the defined order
|
||||
4. When it gets to the network boot device, PXE is run from the firmware on the network card
|
||||
5. PXE will request a BOOTP/DHCP address on the network which is handled by the controller node
|
||||
6. If the DHCP response includes a boot file name, it will download this file (iPXE boot image) over TFTP
|
||||
7. Once iPXE is downloaded, it is loaded by the network card and it will request a configuration from the
|
||||
controller node
|
||||
8. The configuration will tell iPXE what to download and load
|
||||
|
||||
Warewulf manages the entire process once the worker node's network device has begun the PXE process.
|
||||
|
||||
## Warewulf Server
|
||||
|
||||
Warewulf will configure the controller's DHCP and TFTP services and put all the required files into place. But once the iPXE file has been sent and loaded on the worker nodes, all network communication from this point on is handled by the Warewulf server on the controller node over HTTP. The order of events from this point on is as follows:
|
||||
|
||||
1. iPXE requests its configuration and Warewulf generates this on demand from the configured template
|
||||
1. The default iPXE template tells iPXE to request a kernel, VNFS image, runtime kernel modules and a system overlay
|
||||
1. Each of the requested files will be sent to the worker node
|
||||
|
||||
## Post PXE
|
||||
|
||||
Once the worker node has received all the required files, the kernel will boot, and the runtime components will be loaded into the kernel's initial RAM file system (initramfs). The order of these processes is important because each layer is dependent on the previous. The layers are implemented in the following order:
|
||||
|
||||
1. VNFS/Container image
|
||||
1. Kernel modules
|
||||
1. System Overlay
|
||||
1. Runtime Overlay (repeated at a given interval)
|
||||
|
||||
As part of the provisioning process, the system boots after the System Overlay has been provisioned, which means that the Runtime Overlay occurs after `/sbin/init` has been called on the system. This delineation is important because it clearly defines what should be in the system versus runtime overlay. More on overlays in the next section.
|
||||
|
||||
Before calling `/sbin/init` (or `init` to override in the node configuration file), Warewulf must set up the system. Again, this process occurs after the System Overlay has been provisioned. This is where the system initializes and prepares for booting the runtime OS. Depending on the configuration, the system might boot directly in the initramfs file system as it stands, or it could migrate the root file system to a different mount point (e.g. `tmpfs`or at some point, hard drives).
|
||||
|
||||
Other things that get done at this stage are setting up and enabling SELinux, IPMI, making any needed changes or configurations to the file system before booting it and starting up the `wwclient` which is responsible for loading the runtime overlay.
|
||||
|
||||
Lastly, the `init` process is executed with PID 1 and thus "boots" the VNFS container. This is where SysVInit, Upstart, or Systemd takes over.
|
||||
|
||||
## Warewulf Overlays
|
||||
|
||||
As described above, Warewulf uses layers to provision worker nodes in phases. The first layer is static across any number of nodes, but each node may require some custom configurations, for example, network. This means there must be a method for leveraging a base file system (VNFS) that can be shared by many nodes and also be able to configure these file systems with custom per-node options at a large scale.
|
||||
|
||||
Typically, there are two major times this configuration needs to be done-- pre "boot" and post "boot". In this case, as described above, we can consider the call to `/sbin/init` the delineation point and the proper way to consider the two configurable overlays: system and runtime.
|
||||
|
||||
**System Overlay**: The system overlay is what will be present before `/sbin/init` is called. This gives the administrator the ability to control the configuration of the booting system itself. For example, network configuration must be addressed on every node, but each node must have a slightly different network configuration otherwise the IP addresses will clash. This must be set before Systemd brings up the network device, so the Warewulf system overlay is the right place to configure this.
|
||||
|
||||
**Runtime Overlays**: Some configurations happen after the system boots and continuously at periodic intervals. For example, user and group accounts. You probably don't want to reprovision a node, let alone hundreds of nodes, to add a user or change a runtime configuration, and this is where you should use the runtime overlay.
|
||||
|
||||
Both overlays leverage a similar file system template structure. Each overlay (you can create any number of them) can include text files, directories, links and templates. Templates allow you to dynamically customize any of the content within an overlay for each node that will be leveraging that template.
|
||||
39
docs/docs/about/introduction.md
Normal file
39
docs/docs/about/introduction.md
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
id: introduction
|
||||
title: Introduction
|
||||
slug: /
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
Warewulf is an operating system provisioning system for Linux that is designed to produce simple, turnkey HPC deployment solutions that maintain flexibility and configurability at scale.
|
||||
|
||||
Since its initial release in 2001, Warewulf has become the most popular open source and vendor-agnostic provisioning system within the global HPC community. Warewulf is known for its massive scalability and simple management of stateless (disk optional) provisioning.
|
||||
|
||||
In a nutshell, cluster node operating system images are containers. These containers are built into a bootable format called a "Virtual Node File System" (VNFS) image which is provisioned out to nodes when they boot. A VNFS and kernel pair can be distributed to any number of nodes, which means you could have all of your nodes booting the exact same container VNFS image. To avoid the administrative headache of too many customized VNFS images, subtle differences between node operating system configurations are handled with "overlays".
|
||||
|
||||
On boot, each node receives, in the following order:
|
||||
|
||||
1. iPXE boot image (tftp)
|
||||
1. Linux kernel (http)
|
||||
1. VNFS image (http)
|
||||
1. Kernel module overlay (http)
|
||||
1. System overlay (http)
|
||||
|
||||
Once the node has booted, it will request a runtime overlay (privileged http) at a periodic interval.
|
||||
|
||||
All the images which are transferred for provisioning are prebuilt static components and the per node connection processing is minimal. This means that Warewulf is as scalable as the physical infrastructure.
|
||||
|
||||
## Warewulf Design Tenants
|
||||
|
||||
To enable simple, scalable and flexible operating system management at scale.
|
||||
|
||||
- **Lightweight**: Warewulf needs to do its job and stay out of the way. There should be no underlying system dependencies, changes or "stack" for the controller or worker nodes.
|
||||
|
||||
- **Simple**: Warewulf is used by hobbyists, researchers, scientists, engineers and systems administrators. This means that Warewulf must be simple to use and understand.
|
||||
|
||||
- **Flexible**: Warewulf is highly flexible and can address the needs of any environment-- from a computer lab with graphical workstations, to under-the-desk clusters, to massive supercomputing centers providing traditional HPC capabilities to thousands of users.
|
||||
|
||||
- **Agnostic**: From the Linux distribution to the underlying hardware, Warewulf should be as agnostic and standards compliant as possible. From ARM to x86, Atos to Dell, Warewulf can provision it all equally well with no favorites.
|
||||
|
||||
- **Open Source**: It is imperative that Warewulf be and remain absolutely Open Source.
|
||||
4
docs/docs/about/security.md
Normal file
4
docs/docs/about/security.md
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
id: security
|
||||
title: Security
|
||||
---
|
||||
4
docs/docs/about/templating.md
Normal file
4
docs/docs/about/templating.md
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
id: templating
|
||||
title: Templating
|
||||
---
|
||||
22
docs/docs/appendix/glossary.md
Normal file
22
docs/docs/appendix/glossary.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: glossary
|
||||
title: Glossary
|
||||
---
|
||||
|
||||
### Container
|
||||
|
||||
Containers are used by Warewulf as the template for the VNFS image. Warewulf containers can be any type of OCI or Singularity standard image formats but maintained on disk as an "OCI bundle". Warewulf integrates with Docker, Docker Hub, any OCI registery, Singularity, standard chroots, etc.
|
||||
|
||||
### Controller
|
||||
The controller node(s) are the resources responsible for management, control, and administration of the cluster. Historically these systems have been called "master", "head", or "administrative" nodes, but we feel the term "controller" is more appropriate and descriptive of the role of this system.
|
||||
|
||||
### Initramfs
|
||||
|
||||
### Kernel
|
||||
|
||||
### Overlays
|
||||
|
||||
### Virtual Node File System (VNFS)
|
||||
|
||||
### Workers
|
||||
Worker nodes are the systems that are being provisioned by Warewulf. The roles of these systems could be "compute", "storage", "GPU", "IO", etc. which would typically be used as a prefix, for example: "**compute worker node**"
|
||||
104
docs/docs/contributing/contributing.md
Normal file
104
docs/docs/contributing/contributing.md
Normal file
@@ -0,0 +1,104 @@
|
||||
---
|
||||
id: contributing
|
||||
title: Contributing
|
||||
---
|
||||
|
||||
Warewulf is an open source project, meaning we have the challenge of limited resources. We are grateful for any support that you can offer. Helping other users, raising issues, helping write documentation, or contributing code are all ways to help!
|
||||
|
||||
## Join the community
|
||||
|
||||
This is a huge endeavor, and your help would be greatly appreciated! Post to online communities about Warewulf, and request that your distribution vendor, service provider, and system administrators include Warewulf for you!
|
||||
|
||||
### Warewulf Google Group
|
||||
|
||||
If you have been using Warewulf and having good luck with it, join our [Google Group](https://groups.google.com/a/ctrliq.com/forum/#!forum/warewulf) and help out other users!
|
||||
|
||||
### Warewulf on Slack
|
||||
|
||||
Many of our users come to Slack for quick help with an issue. You can find us at [HPCng](https://join.slack.com/t/hpcng/shared_invite/zt-k9atb2dj-rnlPjSh5Os3Ks6vlDEOyAA).
|
||||
|
||||
## Raise an Issue
|
||||
|
||||
For general bugs/issues, you can open an issue [at the GitHub repo](https://github.com/ctrliq/warewulf/issues/new). However, if you find a security related issue/problem, please email Ctrl IQ directly at [security@ctrliq.com](mailto:security@ctrliq.com). More information about the Ctrl IQ security policies and procedures can be found [here](https://ctrliq.com/warewulf/security-policy).
|
||||
|
||||
## Contribute to the code
|
||||
|
||||
We use the traditional [GitHub Flow](https://guides.github.com/introduction/flow) to develop. This means that you fork the main repo, create a new branch to make changes, and submit a pull request (PR) to the master branch.
|
||||
|
||||
Check out our official [CONTRIBUTING.md](https://github.com/ctrliq/warewulf/blob/master/CONTRIBUTING.md) document, which also includes a [code of conduct](https://github.com/ctrliq/warewulf/blob/master/CONTRIBUTING.md#code-of-conduct).
|
||||
|
||||
|
||||
### Step 1. Fork the repo
|
||||
|
||||
To contribute to Warewulf, you should obtain a GitHub account and fork the [Warewulf](https://github.com/ctrliq/warewulf) repository. Once forked, clone your fork of the repo to your computer. (Obviously, you should replace `your-username` with your GitHub username.)
|
||||
|
||||
```bash
|
||||
git clone https://github.com/your-username/warewulf.git
|
||||
cd warewulf
|
||||
```
|
||||
|
||||
### Step 2. Checkout a new branch
|
||||
|
||||
[Branches](https://guides.github.com/introduction/flow) are a way of
|
||||
isolating your features from the main branch. Given that we’ve just cloned the
|
||||
repo, we will probably want to make a new branch from master in which to work on
|
||||
our new feature. Lets call that branch `new-feature`:
|
||||
|
||||
```bash
|
||||
git checkout master
|
||||
git checkout -b new-feature
|
||||
```
|
||||
|
||||
:::note
|
||||
You can always check which branch you are in by running ``git branch``.
|
||||
:::
|
||||
|
||||
### Step 3. Make your changes
|
||||
|
||||
On your new branch, go nuts! Make changes, test them, and when you are happy commit the changes to the branch:
|
||||
|
||||
```bash
|
||||
git add file-changed1 file-changed2...
|
||||
git commit -m "what changed?"
|
||||
```
|
||||
|
||||
This commit message is important - it should describe exactly the changes that you have made. Good commit messages read like so:
|
||||
|
||||
```bash
|
||||
git commit -m "changed function getConfig in functions.go to output csv to fix #2"
|
||||
git commit -m "updated docs about shell to close #10"
|
||||
```
|
||||
|
||||
The tags `close #10` and `fix #2` are referencing issues that are posted on the upstream repo where you will direct your pull request. When your PR is merged into the master branch, these messages will automatically close the issues, and further, they will link your commits directly to the issues they intend to fix. This will help future maintainers understand your contribution, or (hopefully not) revert the code back to a previous version if necessary.
|
||||
|
||||
### Step 4. Push your branch to your fork
|
||||
|
||||
When you are done with your commits, you should push your branch to your fork (and you can also continuously push commits here as you work):
|
||||
|
||||
```bash
|
||||
git push origin new-feature
|
||||
```
|
||||
|
||||
Note that you should always check the status of your branches to see what has been pushed (or not):
|
||||
|
||||
```bash
|
||||
git status
|
||||
```
|
||||
|
||||
### Step 5. Submit a Pull Request
|
||||
Once you have pushed your branch, then you can go to your fork (in the web GUI on GitHub) and [submit a Pull Request](https://help.github.com/articles/creating-a-pull-request). Regardless of the name of your branch, your PR should be submitted to the Ctrl IQ `master` branch. Submitting your PR will open a conversation thread for the maintainers of Warewulf to discuss your contribution. At this time, the continuous integration that is linked with the code base will also be executed. If there is an issue, or if the maintainers suggest changes, you can continue to push commits to your branch and they will update the Pull Request.
|
||||
|
||||
### Step 6. Keep your branch in sync
|
||||
Cloning the repo will create an exact copy of the Warewulf repository at that moment. As you work, your branch may become out of date as others merge changesinto the upstream master. In the event that you need to update a branch, you will need to follow the next steps:
|
||||
|
||||
```bash
|
||||
# add a new remote named "upstream"
|
||||
git remote add upstream https://github.com/ctrliq/warewulf.git
|
||||
# or another branch to be updated
|
||||
git checkout master
|
||||
git pull upstream master
|
||||
# to update your fork
|
||||
git push origin master
|
||||
git checkout new-feature
|
||||
git merge master
|
||||
```
|
||||
127
docs/docs/contributing/development-environment-kvm.md
Normal file
127
docs/docs/contributing/development-environment-kvm.md
Normal file
@@ -0,0 +1,127 @@
|
||||
---
|
||||
id: development-environment-kvm
|
||||
title: Development Environment (KVM)
|
||||
---
|
||||
|
||||
1. Create CentOS 7 development virtual machine under KVM
|
||||
|
||||
```bash
|
||||
# KVM is running on server called master1 which is not my desktop
|
||||
ssh -X master1
|
||||
|
||||
# On master1 server
|
||||
wget -P /global/downloads/centos http://mirror.mobap.edu/centos/7.8.2003/isos/x86_64/CentOS-7-x86_64-Everything-2003.iso
|
||||
|
||||
qemu-img create -o preallocation=metadata -f qcow2 /global/images/centos-7.qcow2 32G
|
||||
|
||||
# install wwdev Centos 7 development VM
|
||||
sudo virt-install --virt-type kvm --name centos7-wwdev --ram 8192 \
|
||||
--disk /global/images/centos-7.qcow2,format=qcow2 \
|
||||
--network network=default \
|
||||
--graphics vnc,listen=0.0.0.0 --noautoconsole \
|
||||
--os-type=linux --os-variant=rhel7.0 \
|
||||
--location=/global/downloads/centos/CentOS-7-x86_64-Everything-2003.iso
|
||||
|
||||
# Complete installation using virt-manager
|
||||
|
||||
# To start virt-manager on non-local server
|
||||
ssh -X master1
|
||||
|
||||
sudo -E virt-manager
|
||||
|
||||
# Login to VM and install @development group and go language
|
||||
ssh root@wwdev
|
||||
|
||||
# Disable selinux by modifying /etc/sysconfig/selinux
|
||||
vi /etc/sysconfig/selinux
|
||||
|
||||
SELINUX=disabled
|
||||
|
||||
# disable firewall
|
||||
systemctl stop firewalld
|
||||
systemctl disable firewalld
|
||||
```
|
||||
|
||||
2. Turn off default network dhcp on server master1
|
||||
|
||||
```bash
|
||||
# shutdown all VMs
|
||||
sudo virsh net-destroy default
|
||||
|
||||
sudo virsh net-edit default
|
||||
|
||||
# remove dhcp lines from XML
|
||||
|
||||
sudo virsh net-start default
|
||||
```
|
||||
|
||||
|
||||
3. Build and install warewulf on wwdev
|
||||
|
||||
```bash
|
||||
ssh wwdev
|
||||
|
||||
# Fedora prerequisites
|
||||
sudo dnf -y install tftp-server tftp
|
||||
sudo dnf -y install dhcp
|
||||
sudo dnf -y install ipmitool
|
||||
sudo dnf install singularity
|
||||
sudo dnf install gpgme-devel
|
||||
sudo dnf install libassuan.x86_64 libassuan-devel.x86_64
|
||||
sudo dnf golang
|
||||
sudo dnf nfs-utils
|
||||
|
||||
# Centos prerequisites
|
||||
sudo yum -y install tftp-server tftp
|
||||
sudo yum -y install dhcp
|
||||
sudo yum -y install ipmitool
|
||||
sudo yum install http://repo.ctrliq.com/packages/rhel7/ctrl-release.rpm
|
||||
sudo yum install singularityplus
|
||||
sudo yum install gpgme-devel
|
||||
sudo yum install libassuan.x86_64 libassuan-devel.x86_64
|
||||
sudo yum install https://packages.endpoint.com/rhel/7/os/x86_64/endpoint-repo-1.7-1.x86_64.rpm
|
||||
sudo yum install golang
|
||||
sudo yum install nfs-utils
|
||||
|
||||
# Install Warewulf and dependencies
|
||||
git clone https://github.com/ctrliq/warewulf.git
|
||||
cd warewulf
|
||||
|
||||
make all
|
||||
sudo make install
|
||||
|
||||
# Configure the controller
|
||||
Edit the file /etc/warewulf/warewulf.conf and ensure that you've ser the approprite configuration parameters
|
||||
|
||||
# Configure system service automatically
|
||||
sudo wwctl configure dhcp # Create the default dhcpd.conf file and start/enable service
|
||||
sudo wwctl configure tftp # Install the base tftp/PXE boot files and start/enable service
|
||||
sudo wwctl configure nfs # Configure the exports and create an fstab in the default system overlay
|
||||
sudo wwctl configure ssh # Build the basic ssh keys to be included by the default system overlay
|
||||
|
||||
# Pull and build the VNFS container and kernel
|
||||
sudo wwctl container import docker://warewulf/centos-8 centos-8 --setdefault
|
||||
sudo wwctl kernel import build $(uname -r) --setdefault
|
||||
|
||||
# Set up the default node profile
|
||||
sudo wwctl profile set default -K $(uname -r) -C centos-7
|
||||
sudo wwctl profile set default --netdev eth0 -M WW_server_subnet_mask -G WW_server_ip
|
||||
sudo wwctl profile list
|
||||
|
||||
# Add a node and build node specific overlays
|
||||
sudo wwctl node add n0000.cluster --netdev eth0 -I n0000_ip --discoverable
|
||||
sudo wwctl node list -a n0000
|
||||
|
||||
# Review Warewulf overlays
|
||||
sudo wwctl overlay list -l
|
||||
sudo wwctl overlay list -ls
|
||||
sudo wwctl overlay edit default /etc/hello_world.ww
|
||||
sudo wwctl overlay build -a
|
||||
|
||||
# Start the Warewulf daemon
|
||||
sudo wwctl ready
|
||||
sudo wwctl server start
|
||||
sudo wwctl server status
|
||||
```
|
||||
|
||||
4. Boot your node and watch the console and the output of the Warewulfd process
|
||||
147
docs/docs/contributing/development-environment-vbox.md
Normal file
147
docs/docs/contributing/development-environment-vbox.md
Normal file
@@ -0,0 +1,147 @@
|
||||
---
|
||||
id: development-environment-vbox
|
||||
title: Development Environment (VirtualBox)
|
||||
---
|
||||
|
||||
I have VirtualBox running on my desktop.
|
||||
|
||||
1. Create a NAT Network (a private vlan) to be used for the Warewlf Server and compute nodes inside the VirtualBox. Make sure to turnoff DHCP service within this NAT Network.
|
||||
|
||||
```bash
|
||||
# On the host with VirtualBox execute below. In my example using 10.0.8.0/24 as the private vlan for my experiment with Warewulf
|
||||
|
||||
VBoxManage natnetwork add --netname wwnatnetwork --network "10.0.8.0/24" --enable --dhcp off
|
||||
```
|
||||
|
||||
2. Create a Centos 7 development Virtual machine (wwdev) to be used as the Warewulf Server. Enable two Network adapters one with a standard NAT and SSH port mapping such that you can access this VM from the host machine. Assign the second network adapter to the NAT Network created in step #1. Assign sufficient memory (e.g: 4GB) to the VM.
|
||||
|
||||
```bash
|
||||
# Download a Centos7 or SL7 ISO and mount it to the optical drive to boot and install OS for the wwdev VM.
|
||||
# Attach Network adapter #1 of the wwdev VM to the standard NAT via VM Settings -> Network option.
|
||||
# By default VirtualBox puts the Network Adapter into 10.0.2.0/24 network and assigns 10.0.2.15 IP address.
|
||||
|
||||
# Also add a rule to the port forwarding table under the standard NAT configuration to allow SSH
|
||||
# from localhost (127.0.0.1) some high port e.g 2222 to the guest IP 10.0.2.15 port 22 such that
|
||||
# you can SSH from your host/desktop to the wwdev VM.
|
||||
|
||||
# Next attach the second Network adapter #2 to the NAT Network and you should be able to choose
|
||||
# the 'wwnatnetwork' created above in step #1 from the drop down list.
|
||||
```
|
||||
|
||||
3. Build and install warewulf on wwdev
|
||||
|
||||
```bash
|
||||
# Login to wwdev VM and install @development group and go language
|
||||
|
||||
ssh localhost -p 2222 #(should prompt for a user account password on wwdev VM)
|
||||
|
||||
# Disable selinux by modifying /etc/sysconfig/selinux
|
||||
vi /etc/sysconfig/selinux
|
||||
|
||||
SELINUX=disabled
|
||||
|
||||
# Disable firewall
|
||||
systemctl stop firewalld
|
||||
systemctl disable firewalld
|
||||
|
||||
# Centos prerequisites
|
||||
sudo yum -y install tftp-server tftp
|
||||
sudo yum -y install dhcp
|
||||
sudo yum -y install ipmitool
|
||||
sudo yum install http://repo.ctrliq.com/packages/rhel7/ctrl-release.rpm
|
||||
sudo yum install singularityplus
|
||||
sudo yum install gpgme-devel
|
||||
sudo yum install libassuan.x86_64 libassuan-devel.x86_64
|
||||
|
||||
# Upgrade git to v2+
|
||||
sudo yum install https://packages.endpoint.com/rhel/7/os/x86_64/endpoint-repo-1.7-1.x86_64.rpm
|
||||
sudo yum install git
|
||||
sudo yum install golang
|
||||
sudo yum install nfs-utils
|
||||
|
||||
# Install Warewulf and dependencies
|
||||
git clone https://github.com/ctrliq/warewulf.git
|
||||
cd warewulf
|
||||
|
||||
make all
|
||||
sudo make install
|
||||
|
||||
# Static assign an IP to adapter #2 which is in the wwnatnetwork.
|
||||
$ Edit the file /etc/sysconfig/networking-scripts/ifcfg-enp0s9 # adapter name at the end might be different for you
|
||||
# Add lines like to below to assign an ip in 10.0.8.0/24 wwnatnetwork, I choose 10.0.8.4
|
||||
BOOTPROTO=static
|
||||
ONBOOT=yes
|
||||
NAME=enp0s9
|
||||
DEVICE=enp0s9
|
||||
IPADDR=10.0.8.4
|
||||
NETMASK=255.255.255.0
|
||||
GATEWAY=10.0.8.1
|
||||
# Bring the enp0s9 interface online and verify ip assignment
|
||||
|
||||
# Configure the Warewulf controller
|
||||
$ Edit the file /etc/warewulf/warewulf.conf and ensure that you've set the approprite configuration parameters.
|
||||
# My conf file looks like below:
|
||||
ipaddr: 10.0.8.4
|
||||
netmask: 255.255.255.0
|
||||
warewulf:
|
||||
port: 9873
|
||||
secure: true
|
||||
update interval: 60
|
||||
dhcp:
|
||||
enabled: true
|
||||
range start: 10.0.8.150
|
||||
range end: 10.0.8.200
|
||||
template: default
|
||||
systemd name: dhcpd
|
||||
tftp:
|
||||
enabled: true
|
||||
tftproot: /var/lib/tftpboot
|
||||
systemd name: tftp
|
||||
nfs:
|
||||
systemd name: nfs-server
|
||||
exports:
|
||||
- /home
|
||||
- /var/warewulf
|
||||
|
||||
# Configure system service automatically
|
||||
sudo wwctl configure dhcp --persist # Create the default dhcpd.conf file and start/enable service
|
||||
sudo wwctl configure tftp --persist # Install the base tftp/PXE boot files and start/enable service
|
||||
sudo wwctl configure nfs --persist # Configure the exports and create an fstab in the default system overlay
|
||||
sudo wwctl configure ssh --persist # Build the basic ssh keys to be included by the default system overlay
|
||||
|
||||
# Pull and build the VNFS container and kernel
|
||||
sudo wwctl container import docker://warewulf/centos-7 centos-7 --setdefault
|
||||
sudo wwctl kernel import build $(uname -r) --setdefault
|
||||
|
||||
# Set up the default node profile
|
||||
sudo wwctl profile set default -K $(uname -r) -C centos-7
|
||||
sudo wwctl profile set default --netdev eth0 -M 255.255.255.0 -G 10.0.8.4
|
||||
sudo wwctl profile list
|
||||
|
||||
# Add a node and build node specific overlays
|
||||
# IP address of my nodes start from 150 as set in the warewulf.conf file above
|
||||
sudo wwctl node add n0000.cluster --netdev eth0 -I 10.0.8.150 --discoverable
|
||||
sudo wwctl node list -a n0000
|
||||
|
||||
# Review Warewulf overlays
|
||||
sudo wwctl overlay list -l
|
||||
sudo wwctl overlay list -ls
|
||||
sudo wwctl overlay edit default /etc/hello_world.ww
|
||||
sudo wwctl overlay build -a
|
||||
|
||||
# Start the Warewulf daemon
|
||||
sudo wwctl ready
|
||||
sudo wwctl server start
|
||||
sudo wwctl server status
|
||||
```
|
||||
|
||||
4. Create a new guest VM instance inside the VirtualBox to be the warewulf client/compute node. Under the system configuration make sure to select the optical and network options only for the boot order. The default iPXE used by VirtualBox does not come with bzImage capability which is needed for warewulf. Download the ipxe.iso available at ipxe.org and mount the ipxe.iso to the optical drive. Enable one Network adapter for this VM and assign it to the NAT Network created in step #1 above.
|
||||
|
||||
```bash
|
||||
# Download ipxe.so available at http://boot.ipxe.org/ipxe.iso
|
||||
# VM Settings -> System disable Floppy, Hard Disk from Boot order. Enable Optical and Network options.
|
||||
# VM Settings -> Storage and mount the above download ipxe.so to the Optical Drive.
|
||||
# VM Settings -> Network Enable adapter #1, attach to 'Nat Network' and choose 'wwnatnetwork' from the drop down list.
|
||||
```
|
||||
|
||||
5. Boot your node and watch the console and the output of the Warewulfd process
|
||||
22
docs/docs/contributing/documentation.md
Normal file
22
docs/docs/contributing/documentation.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: documentation
|
||||
title: Documentation
|
||||
---
|
||||
|
||||
We (like almost all open source software providers) have a documentation dilemma… We tend to focus on the code features and functionality before working on documentation. And there is very good reason for this: we want to share the love so nobody feels left out!
|
||||
|
||||
You can contribute to the documentation by [raising an issue to suggest an improvement](https://github.com/ctrliq/warewulf-docs/issues/new) or by sending a [pull request](https://github.com/ctrliq/warewulf-docs/compare) on [our repository for documentation](https://github.com/ctrliq/warewulf-docs).
|
||||
|
||||
The current documentation is generated with:
|
||||
|
||||
- [reStructured Text (RST)](http://docutils.sourceforge.net/rst.html) and [ReadTheDocs](https://readthedocs.org).
|
||||
|
||||
Other dependencies include:
|
||||
|
||||
- [Python 3.5 or newer](https://www.python.org/downloads)
|
||||
|
||||
- [Sphinx](https://pypi.org/project/Sphinx)
|
||||
|
||||
More information about contributing to the documentation, instructions on how to install the dependencies, and how to generate the files can be obtained [here](https://github.com/ctrliq/warewulf-docs/blob/master/README.md).
|
||||
|
||||
For more information on using Git and GitHub to create a pull request suggesting additions and edits to the docs, see the [section on contributing to the code](contributing). The procedure is identical for contributions to the documentation and the code base.
|
||||
138
docs/docs/getting-started/quickstart-el7.md
Normal file
138
docs/docs/getting-started/quickstart-el7.md
Normal file
@@ -0,0 +1,138 @@
|
||||
---
|
||||
id: quickstart-el7
|
||||
title: Quick Start for RHEL and CentOS 7
|
||||
---
|
||||
|
||||
Install Warewulf and dependencies
|
||||
=================================
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo yum install epel-release
|
||||
$ sudo yum install golang tftp-server dhcp nfs-utils
|
||||
|
||||
$ sudo systemctl stop firewalld
|
||||
$ sudo systemctl disable firewalld
|
||||
|
||||
$ git clone https://github.com/ctrliq/warewulf.git
|
||||
$ cd warewulf
|
||||
$ make all
|
||||
$ sudo make install
|
||||
|
||||
Configure the controller
|
||||
========================
|
||||
|
||||
Edit the file ``/etc/warewulf/warewulf.conf`` and ensure that you've set the appropriate configuration paramaters. Here are some of the defaults for reference:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
ipaddr: 192.168.1.1
|
||||
netmask: 255.255.255.0
|
||||
warewulf:
|
||||
port: 9873
|
||||
secure: true
|
||||
update interval: 60
|
||||
dhcp:
|
||||
enabled: true
|
||||
range start: 192.168.1.150
|
||||
range end: 192.168.1.200
|
||||
template: default
|
||||
systemd name: dhcpd
|
||||
tftp:
|
||||
enabled: true
|
||||
tftproot: /var/lib/tftpboot
|
||||
systemd name: tftp
|
||||
nfs:
|
||||
systemd name: nfs-server
|
||||
exports:
|
||||
- /home
|
||||
- /var/warewulf
|
||||
|
||||
Configure system services automatically
|
||||
=======================================
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo wwctl configure dhcp # Create the default dhcpd.conf file and start/enable service
|
||||
$ sudo wwctl configure tftp # Install the base tftp/PXE boot files and start/enable service
|
||||
$ sudo wwctl configure nfs # Configure the exports and create an fstab in the default system overlay
|
||||
$ sudo wwctl configure ssh # Build the basic ssh keys to be included by the default system overlay
|
||||
|
||||
Pull and build the VNFS container and kernel
|
||||
============================================
|
||||
|
||||
This will pull a basic VNFS container from Docker Hub and import the default running kernel from the controller node and set both in the "default" node profile.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo wwctl container import docker://warewulf/centos-7 centos-7 --setdefault
|
||||
$ sudo wwctl kernel import $(uname -r) --setdefault
|
||||
|
||||
Set up the default node profile
|
||||
===============================
|
||||
|
||||
The ``--setdefault`` arguments above will automatically set those entries in the default profile, but if you wanted to set them by hand to something different, you can do the following:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo wwctl profile set default -K $(uname -r) -C centos-7
|
||||
|
||||
Next we set some default networking configurations for the first ethernet device. On modern Linux distributions, the name of the device is not critical, as it will be setup according to the HW address. Because all nodes will share the netmask and gateway configuration, we can set them in the default profile as follows:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo wwctl profile set default --netdev eth0 -M 255.255.255.0 -G 192.168.1.1
|
||||
$ sudo wwctl profile list
|
||||
|
||||
Add a node and build node specific overlays
|
||||
===========================================
|
||||
|
||||
Adding nodes can be done while setting configurations in one command. Here we are setting the IP address of ``eth0`` and setting this node to be discoverable, which will then automatically have the HW address added to the configuration as the node boots.
|
||||
|
||||
Node names must be unique. If you have node groups and/or multiple clusters, designate them using dot notation.
|
||||
|
||||
Note that the full node configuration comes from both cascading profiles and node configurations which always supersede profile configurations.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo wwctl node add n0000.cluster --netdev eth0 -I 192.168.1.100 --discoverable
|
||||
$ sudo wwctl node list -a n0000
|
||||
|
||||
Warewulf Overlays
|
||||
=================
|
||||
|
||||
There are two types of overlays: system and runtime overlays.
|
||||
|
||||
System overlays are provisioned to the node before ``/sbin/init`` is called. This enables us to prepopulate node configurations with content that is node specific like networking and service configurations.
|
||||
|
||||
Runtime overlays are provisioned after the node has booted and periodically during the normal runtime of the node. Because these overlays are provisioned at periodic intervals, they are very useful for content that changes, like users and groups.
|
||||
|
||||
Overlays are generated from a template structure that is viewed using the ``wwctl overlay`` commands. Files that end in the ``.ww`` suffix are templates and abide by standard text/template rules. This supports loops, arrays, variables, and functions making overlays extremely flexible.
|
||||
|
||||
.. note::
|
||||
When using the overlay subsystem, system overlays are never shown by default. So when running ``overlay`` commands, you are always looking at runtime overlays unless the ``-s`` option is passed.
|
||||
|
||||
All overlays are compiled before being provisioned. This accelerates the provisioning process because there is less to do when nodes are being managed at scale.
|
||||
|
||||
Here are some of the common ``overlay`` commands:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo wwctl overlay list -l
|
||||
$ sudo wwctl overlay list -ls
|
||||
$ sudo wwctl overlay edit default /etc/hello_world.ww
|
||||
$ sudo wwctl overlay build -a
|
||||
|
||||
Start the Warewulf daemon
|
||||
-------------------------
|
||||
|
||||
Once the above provisioning images are built, you can check the provisioning "rediness" and then begin booting nodes.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo wwctl ready
|
||||
$ sudo wwctl server start
|
||||
$ sudo wwctl server status
|
||||
|
||||
Boot your compute node and watch it boot
|
||||
----------------------------------------
|
||||
160
docs/docs/getting-started/quickstart-el8.md
Normal file
160
docs/docs/getting-started/quickstart-el8.md
Normal file
@@ -0,0 +1,160 @@
|
||||
---
|
||||
id: quickstart-el8
|
||||
title: Quick Start for RHEL, CentOS, and Rocky 8
|
||||
---
|
||||
|
||||
Install Warewulf and dependencies
|
||||
=================================
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo dnf groupinstall "Development Tools"
|
||||
$ sudo dnf install epel-release
|
||||
$ sudo dnf install golang tftp-server dhcp-server nfs-utils
|
||||
|
||||
$ sudo systemctl stop firewalld
|
||||
$ sudo systemctl disable firewalld
|
||||
|
||||
$ git clone https://github.com/ctrliq/warewulf.git
|
||||
$ cd warewulf
|
||||
$ make all
|
||||
$ sudo make install
|
||||
|
||||
Configure the controller
|
||||
=========================
|
||||
|
||||
Edit the file ``/etc/warewulf/warewulf.conf`` and ensure that you've set the
|
||||
appropriate configuration paramaters. Here are some of the defaults for reference:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
ipaddr: 192.168.1.1
|
||||
netmask: 255.255.255.0
|
||||
warewulf:
|
||||
port: 9873
|
||||
secure: true
|
||||
update interval: 60
|
||||
dhcp:
|
||||
enabled: true
|
||||
range start: 192.168.1.150
|
||||
range end: 192.168.1.200
|
||||
template: default
|
||||
systemd name: dhcpd
|
||||
tftp:
|
||||
enabled: true
|
||||
tftproot: /var/lib/tftpboot
|
||||
systemd name: tftp
|
||||
nfs:
|
||||
systemd name: nfs-server
|
||||
exports:
|
||||
- /home
|
||||
- /var/warewulf
|
||||
|
||||
Configure system services automatically
|
||||
=======================================
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo wwctl configure dhcp # Create the default dhcpd.conf file and start/enable service
|
||||
$ sudo wwctl configure tftp # Install the base tftp/PXE boot files and start/enable service
|
||||
$ sudo wwctl configure nfs # Configure the exports and create an fstab in the default system overlay
|
||||
$ sudo wwctl configure ssh # Build the basic ssh keys to be included by the default system overlay
|
||||
|
||||
|
||||
Pull and build the VNFS container and kernel
|
||||
============================================
|
||||
|
||||
This will pull a basic VNFS container from Docker Hub and import the default running
|
||||
kernel from the controller node and set both in the "default" node profile.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo wwctl container import docker://warewulf/centos-8 centos-8 --setdefault
|
||||
$ sudo wwctl kernel import $(uname -r) --setdefault
|
||||
|
||||
Set up the default node profile
|
||||
===============================
|
||||
|
||||
The ``--setdefault`` arguments above will automatically set those entries in the default
|
||||
profile, but if you wanted to set them by hand to something different, you can do the
|
||||
following:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo wwctl profile set default -K $(uname -r) -C centos-7
|
||||
|
||||
Next we set some default networking configurations for the first ethernet device. On
|
||||
modern Linux distributions, the name of the device is not critical, as it will be setup
|
||||
according to the HW address. Because all nodes will share the netmask and gateway
|
||||
configuration, we can set them in the default profile as follows:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo wwctl profile set default --netdev eth0 -M 255.255.255.0 -G 192.168.1.1
|
||||
$ sudo wwctl profile list
|
||||
|
||||
Add a node and build node specific overlays
|
||||
===========================================
|
||||
|
||||
Adding nodes can be done while setting configurations in one command. Here we are setting
|
||||
the IP address of ``eth0`` and setting this node to be discoverable, which will then
|
||||
automatically have the HW address added to the configuration as the node boots.
|
||||
|
||||
Node names must be unique. If you have node groups and/or multiple clusters, designate
|
||||
them using dot notation.
|
||||
|
||||
Note that the full node configuration comes from both cascading profiles and node
|
||||
configurations which always supersede profile configurations.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo wwctl node add n0000.cluster --netdev eth0 -I 192.168.1.100 --discoverable
|
||||
$ sudo wwctl node list -a n0000
|
||||
|
||||
Warewulf Overlays
|
||||
=================
|
||||
|
||||
There are two types of overlays: system and runtime overlays.
|
||||
|
||||
System overlays are provisioned to the node before ``/sbin/init`` is called. This enables us
|
||||
to prepopulate node configurations with content that is node specific like networking and
|
||||
service configurations.
|
||||
|
||||
Runtime overlays are provisioned after the node has booted and periodically during the
|
||||
normal runtime of the node. Because these overlays are provisioned at periodic intervals,
|
||||
they are very useful for content that changes, like users and groups.
|
||||
|
||||
Overlays are generated from a template structure that is viewed using the ``wwctl overlay``
|
||||
commands. Files that end in the ``.ww`` suffix are templates and abide by standard
|
||||
text/template rules. This supports loops, arrays, variables, and functions making overlays
|
||||
extremely flexible.
|
||||
|
||||
.. note::
|
||||
When using the overlay subsystem, system overlays are never shown by default. So when running ``overlay`` commands, you are always looking at runtime overlays unless the ``-s`` option is passed.
|
||||
|
||||
All overlays are compiled before being provisioned. This accelerates the provisioning
|
||||
process because there is less to do when nodes are being managed at scale.
|
||||
|
||||
Here are some of the common ``overlay`` commands:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo wwctl overlay list -l
|
||||
$ sudo wwctl overlay list -ls
|
||||
$ sudo wwctl overlay edit default /etc/hello_world.ww
|
||||
$ sudo wwctl overlay build -a
|
||||
|
||||
Start the Warewulf daemon
|
||||
-------------------------
|
||||
|
||||
Once the above provisioning images are built, you can check the provisioning "rediness"
|
||||
and then begin booting nodes.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo wwctl ready
|
||||
$ sudo wwctl server start
|
||||
$ sudo wwctl server status
|
||||
|
||||
Boot your compute node and watch it boot
|
||||
----------------------------------------
|
||||
4
docs/docs/prerequisites/hardware.md
Normal file
4
docs/docs/prerequisites/hardware.md
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
id: hardware
|
||||
title: Hardware
|
||||
---
|
||||
4
docs/docs/prerequisites/software.md
Normal file
4
docs/docs/prerequisites/software.md
Normal file
@@ -0,0 +1,4 @@
|
||||
---
|
||||
id: software
|
||||
title: Software
|
||||
---
|
||||
48
docs/docs/wwctl/configure.md
Normal file
48
docs/docs/wwctl/configure.md
Normal file
@@ -0,0 +1,48 @@
|
||||
---
|
||||
id: configure
|
||||
title: wwctl configure
|
||||
---
|
||||
|
||||
Commands in this command group manage and initialize services Warewulf depends on, based on the configuration in `warewulf.conf`.
|
||||
|
||||
## dhcp
|
||||
DHCP is a dependent service to Warewulf. This command will configure DHCP as defined.
|
||||
|
||||
### -s, --show
|
||||
Show configuration (don't update)
|
||||
|
||||
### --persist
|
||||
Persist the configuration and initialize the service
|
||||
|
||||
## hosts
|
||||
Write out the /etc/hosts file based on the Warewulf template (hosts.tmpl) in the Warewulf configuration directory.
|
||||
|
||||
### -s, --show
|
||||
Show configuration (don't update)
|
||||
|
||||
### --persist
|
||||
Persist the configuration and initialize the service
|
||||
|
||||
## nfs
|
||||
NFS is an optional dependent service of Warewulf, this tool will automatically configure NFS as per the configuration in the warewulf.conf file.
|
||||
|
||||
### -s, --show
|
||||
Show configuration (don't update)
|
||||
|
||||
### --persist
|
||||
Persist the configuration and initialize the service
|
||||
|
||||
## ssh
|
||||
SSH is an optionally dependent service for Warewulf, this tool will automatically setup the ssh keys nodes using the 'default' system overlay as well as user owned keys.
|
||||
|
||||
### --persist
|
||||
Persist the configuration and initialize the service
|
||||
|
||||
## tftp
|
||||
TFTP is a dependent service of Warewulf, this tool will enable the tftp services on your Warewulf master.
|
||||
|
||||
### -s, --show
|
||||
Show configuration (don't update)
|
||||
|
||||
### --persist
|
||||
Persist the configuration and initialize the service
|
||||
35
docs/docs/wwctl/container.md
Normal file
35
docs/docs/wwctl/container.md
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
id: container
|
||||
title: wwctl container
|
||||
---
|
||||
|
||||
Starting with version 4, Warewulf uses containers to build the bootable VNFS images for nodes to boot. These commands will help you import, management, and transform containers into bootable Warewulf VNFS images.
|
||||
|
||||
build
|
||||
~~~~~
|
||||
This command will build a bootable VNFS image from an imported container image.
|
||||
|
||||
-a, --all (re)Build all VNFS images for all nodes
|
||||
-f, --force Force rebuild, even if it isn't necessary
|
||||
--setdefault Set this container for the default profile
|
||||
|
||||
delete
|
||||
~~~~~~
|
||||
This command will delete a container that has been imported into Warewulf.
|
||||
|
||||
exec
|
||||
~~~~
|
||||
This command will allow you to run any command inside of a given warewulf container. This is commonly used with an interactive shell such as ``/bin/bash`` to run a virtual environment within the container.
|
||||
|
||||
imprt
|
||||
~~~~~
|
||||
This command will pull and import a container into Warewulf so it can be used as a source to create a bootable VNFS image.
|
||||
|
||||
-f, --force Force overwrite of an existing container
|
||||
-u, --update Update and overwrite an existing container
|
||||
-b, --build Build container when after pulling
|
||||
--setdefault Set this container for the default profile
|
||||
|
||||
list, ls
|
||||
~~~~~~~~
|
||||
This command will show you the containers that are imported into Warewulf.
|
||||
23
docs/docs/wwctl/controller.md
Normal file
23
docs/docs/wwctl/controller.md
Normal file
@@ -0,0 +1,23 @@
|
||||
---
|
||||
id: controller
|
||||
title: wwctl controller
|
||||
---
|
||||
|
||||
Management of group settings and power management
|
||||
|
||||
add
|
||||
~~~
|
||||
|
||||
delete
|
||||
~~~~~~
|
||||
|
||||
list
|
||||
~~~~
|
||||
-a, --all Show all node configurations
|
||||
|
||||
set
|
||||
~~~
|
||||
-a, --all Set all controllers
|
||||
-I, --ipaddr Set the controller's IP address
|
||||
-F, --fqdn Set the controller's FQDN
|
||||
-C, --comment Comments describing this controller
|
||||
19
docs/docs/wwctl/kernel.md
Normal file
19
docs/docs/wwctl/kernel.md
Normal file
@@ -0,0 +1,19 @@
|
||||
---
|
||||
id: kernel
|
||||
title: wwctl kernel
|
||||
---
|
||||
|
||||
This command is for management of Warewulf Kernels to be used for bootstrapping nodes.
|
||||
|
||||
imprt
|
||||
~~~~~
|
||||
This will import a Kernel version from the control node into Warewulf for nodes to be configured to boot on.
|
||||
|
||||
-a, --all Build all overlays (runtime and system)
|
||||
-n, --node Build overlay for a particular node(s)
|
||||
-r, --root Import kernel from root (chroot) directory
|
||||
--setdefault Set this kernel for the default profile
|
||||
|
||||
list, ls
|
||||
~~~~~~~~
|
||||
This command will list the kernels that have been imported into Warewulf.
|
||||
79
docs/docs/wwctl/node.md
Normal file
79
docs/docs/wwctl/node.md
Normal file
@@ -0,0 +1,79 @@
|
||||
---
|
||||
id: node
|
||||
title: wwctl node
|
||||
---
|
||||
|
||||
Management of node settings
|
||||
|
||||
add
|
||||
~~~
|
||||
This command will add a new node to Warewulf.
|
||||
|
||||
-g, --group Group to add nodes to
|
||||
-c, --controller Controller to add nodes to
|
||||
-N, --netdevDefine the network device to configure
|
||||
-I, --ipaddrSet the node's network device IP address
|
||||
-M, --netmaskSet the node's network device netmask
|
||||
-G, --gatewaySet the node's network device gateway
|
||||
-H, --hwaddrSet the node's network device HW address
|
||||
--discoverable Make this node discoverable
|
||||
|
||||
console
|
||||
~~~~~~~
|
||||
Start IPMI console for a singe node.
|
||||
|
||||
delete
|
||||
~~~~~~
|
||||
This command will remove a node from the Warewulf node configuration.
|
||||
|
||||
-f, --force Force node delete
|
||||
-g, --group Set group to delete nodes from
|
||||
-c, --controller Controller to add nodes to
|
||||
|
||||
list
|
||||
~~~~
|
||||
This command will show you configured nodes.
|
||||
|
||||
-n, --net Show node network configurations
|
||||
-i, --ipmi Show node IPMI configurations
|
||||
-a, --all Show all node configurations
|
||||
-l, --long Show long or wide format
|
||||
|
||||
sensors
|
||||
~~~~~~~
|
||||
Show IPMI sensors for a single node.
|
||||
-F, --full show detailed output
|
||||
|
||||
set
|
||||
~~~
|
||||
This command will allow you to set configuration properties for nodes.
|
||||
|
||||
--comment Set a comment for this node
|
||||
-C, --container Set the container (VNFS) for this node
|
||||
-K, --kernel Set Kernel version for nodes
|
||||
-A, --kernelargs Set Kernel argument for nodes
|
||||
-c, --cluster Set the node's cluster group
|
||||
-P, --ipxe Set the node's iPXE template name
|
||||
-i, --init Define the init process to boot the container
|
||||
--root Define the rootfs
|
||||
-R, --runtime Set the node's runtime overlay
|
||||
-S, --system Set the node's system overlay
|
||||
--ipmi Set the node's IPMI IP address
|
||||
--ipminetmask Set the node's IPMI netmask
|
||||
--ipmigateway Set the node's IPMI gateway
|
||||
--ipmiuser Set the node's IPMI username
|
||||
--ipmipass Set the node's IPMI password
|
||||
-p, --addprofile Add Profile(s) to node
|
||||
-r, --delprofile Remove Profile(s) to node
|
||||
-N, --netdev Define the network device to configure
|
||||
-I, --ipaddr Set the node's network device IP address
|
||||
-M, --netmask Set the node's network device netmask
|
||||
-G, --gateway Set the node's network device gateway
|
||||
-H, --hwaddr Set the node's network device HW address
|
||||
--netdel Delete the node's network device
|
||||
--netdefault Set this network to be default
|
||||
-a, --all Set all nodes
|
||||
-y, --yes Set 'yes' to all questions asked
|
||||
-f, --force Force configuration (even on error)
|
||||
--discoverable Make this node discoverable
|
||||
--undiscoverable Remove the discoverable flag
|
||||
76
docs/docs/wwctl/overlay.md
Normal file
76
docs/docs/wwctl/overlay.md
Normal file
@@ -0,0 +1,76 @@
|
||||
---
|
||||
id: overlay
|
||||
title: wwctl overlay
|
||||
---
|
||||
|
||||
Management interface for Warewulf overlays
|
||||
|
||||
build
|
||||
~~~~~
|
||||
This command will build a system or runtime overlay.
|
||||
|
||||
-s, --system Show System Overlays as well
|
||||
-a, --all Build all overlays (runtime and system)
|
||||
|
||||
chmod
|
||||
~~~~~
|
||||
This command will allow you to change the permissions of a file within an overlay.
|
||||
|
||||
-s, --system Show System Overlays as well
|
||||
-n, --noupdate Don't update overlays
|
||||
|
||||
create
|
||||
~~~~~~
|
||||
This command will create a new empty overlay.
|
||||
|
||||
-s, --system Show System Overlays as well
|
||||
-n, --noupdate Don't update overlays
|
||||
|
||||
delete
|
||||
~~~~~~
|
||||
This command will delete files within an overlay or an entire overlay if no files are given to remove (use with caution).
|
||||
|
||||
-s, --system Show system overlays instead of runtime
|
||||
-f, --force Force deletion of a non-empty overlay
|
||||
-p, --parents Remove empty parent directories
|
||||
-n, --noupdate Don't update overlays
|
||||
|
||||
edit
|
||||
~~~~
|
||||
This command will allow you to edit or create a new file within a given overlay. Note: when creating files ending in a '.ww' suffix this will always be parsed as a Warewulf template file, and the suffix will be removed automatically
|
||||
|
||||
-s, --system Show system overlays instead of runtime
|
||||
-f, --files List files contained within a given overlay
|
||||
-p, --parents Create any necessary parent directories
|
||||
-m, --mode Permission mode for directory
|
||||
-n, --noupdate Don't update overlays
|
||||
|
||||
imprt
|
||||
~~~~~
|
||||
This command will import a file into a given Warewulf overlay.
|
||||
|
||||
-s, --system Show system overlays instead of runtime
|
||||
-m, --mode Permission mode for directory
|
||||
-n, --noupdate Don't update overlays
|
||||
|
||||
list
|
||||
~~~~
|
||||
This command will show you information about Warewulf overlays and the files contained within.
|
||||
|
||||
-s, --system Show system overlays instead of runtime
|
||||
-a, --all List the contents of overlays
|
||||
-l, --long List 'long' of all overlay contents
|
||||
|
||||
mkdir
|
||||
~~~~~
|
||||
This command will allow you to create a new file within a given Warewulf overlay.
|
||||
|
||||
-s, --system Show System Overlays as well
|
||||
-m, --mode Permission mode for directory
|
||||
-n, --noupdate Don't update overlays
|
||||
|
||||
show
|
||||
~~~~
|
||||
This command will output the contents of a file within a given
|
||||
|
||||
-s, --system Show System Overlays as well
|
||||
22
docs/docs/wwctl/power.md
Normal file
22
docs/docs/wwctl/power.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: power
|
||||
title: wwctl power
|
||||
---
|
||||
|
||||
This command can control the power state of nodes.
|
||||
|
||||
cycle
|
||||
~~~~~
|
||||
This command will cycle the power for a given set of nodes.
|
||||
|
||||
off
|
||||
~~~
|
||||
This command will shutdown the power to a given set of nodes.
|
||||
|
||||
on
|
||||
~~
|
||||
This command will power on a given set of nodes.
|
||||
|
||||
status
|
||||
~~~~~~
|
||||
Show power status for the given node(s)
|
||||
46
docs/docs/wwctl/profile.md
Normal file
46
docs/docs/wwctl/profile.md
Normal file
@@ -0,0 +1,46 @@
|
||||
---
|
||||
id: profile
|
||||
title: wwctl profile
|
||||
---
|
||||
|
||||
Management of node profile settings
|
||||
|
||||
add
|
||||
~~~
|
||||
This command will add a new node profile.
|
||||
|
||||
delete
|
||||
~~~~~~
|
||||
This command will delete a node profile.
|
||||
|
||||
list
|
||||
~~~~
|
||||
This command will list and show the profile configurations.
|
||||
|
||||
set
|
||||
~~~
|
||||
This command will allow you to set configuration properties for node profiles.
|
||||
|
||||
--comment Set a comment for this node
|
||||
-C, --container Set the container (VNFS) for this node
|
||||
-K, --kernel Set Kernel version for nodes
|
||||
-A, --kernelargs Set Kernel argument for nodes
|
||||
-c, --cluster Set the node's cluster group
|
||||
-P, --ipxe Set the node's iPXE template name
|
||||
-i, --init Define the init process to boot the container
|
||||
--root Define the rootfs
|
||||
-R, --runtime Set the node's runtime overlay
|
||||
-S, --system Set the node's system overlay
|
||||
--ipminetmask Set the node's IPMI netmask
|
||||
--ipmigateway Set the node's IPMI gateway
|
||||
--ipmiuser Set the node's IPMI username
|
||||
--ipmipass Set the node's IPMI password
|
||||
-N, --netdev Define the network device to configure
|
||||
-I, --ipaddr Set the node's network device IP address
|
||||
-M, --netmask Set the node's network device netmask
|
||||
-G, --gateway Set the node's network device gateway
|
||||
-H, --hwaddr Set the node's network device HW address
|
||||
--netdel Delete the node's network device
|
||||
--netdefault Set this network to be default
|
||||
-a, --all Set all profiles
|
||||
-f, --force Force configuration (even on error)
|
||||
6
docs/docs/wwctl/ready.md
Normal file
6
docs/docs/wwctl/ready.md
Normal file
@@ -0,0 +1,6 @@
|
||||
---
|
||||
id: ready
|
||||
title: wwctl ready
|
||||
---
|
||||
|
||||
Warewulf Status Check
|
||||
20
docs/docs/wwctl/server.md
Normal file
20
docs/docs/wwctl/server.md
Normal file
@@ -0,0 +1,20 @@
|
||||
---
|
||||
id: server
|
||||
title: wwctl server
|
||||
---
|
||||
|
||||
This command will allow you to control the Warewulf daemon process.
|
||||
|
||||
start
|
||||
~~~~~
|
||||
Start Warewulf server
|
||||
|
||||
-f, --foreground Run daemon process in the foreground
|
||||
|
||||
status
|
||||
~~~~~~
|
||||
Warewulf server status
|
||||
|
||||
stop
|
||||
~~~~
|
||||
Stop Warewulf server
|
||||
30
docs/docs/wwctl/wwctl.md
Normal file
30
docs/docs/wwctl/wwctl.md
Normal file
@@ -0,0 +1,30 @@
|
||||
---
|
||||
id: wwctl
|
||||
title: wwctl
|
||||
slug: /wwctl
|
||||
---
|
||||
|
||||
Control interface to the Cluster Warewulf Provisioning System
|
||||
|
||||
## Synopsis
|
||||
|
||||
`wwctl [GLOBAL OPTIONS] [SUBCOMMAND]`
|
||||
|
||||
## Options
|
||||
|
||||
### -d, --debug
|
||||
Run with debugging messages enabled
|
||||
|
||||
### -v, --verbose
|
||||
Run with increased verbosity
|
||||
|
||||
## Environment
|
||||
|
||||
### WAREWULF_OCI_NOHTTPS
|
||||
Skip TLS verification when connecting to an OCI registry
|
||||
|
||||
### WAREWULF_OCI_PASSWORD
|
||||
OCI registry password used in `wwctl container imprt`
|
||||
|
||||
### WAREWULF_OCI_USERNAME
|
||||
OCI registry username used in `wwctl container imprt`
|
||||
97
docs/docusaurus.config.js
Normal file
97
docs/docusaurus.config.js
Normal file
@@ -0,0 +1,97 @@
|
||||
module.exports = {
|
||||
title: 'Warewulf',
|
||||
tagline: 'A stateless and diskless container operating system provisioning system for large clusters of bare metal and/or virtual systems.',
|
||||
url: 'https://ctrliq.github.io',
|
||||
baseUrl: '/warewulf/',
|
||||
onBrokenLinks: 'throw',
|
||||
onBrokenMarkdownLinks: 'warn',
|
||||
favicon: 'img/favicon.png',
|
||||
organizationName: 'ctrliq',
|
||||
projectName: 'warewulf',
|
||||
themeConfig: {
|
||||
navbar: {
|
||||
title: 'Warewulf',
|
||||
logo: {
|
||||
alt: 'Warewulf Logo',
|
||||
src: 'img/logo.png',
|
||||
},
|
||||
items: [
|
||||
{
|
||||
to: 'docs/',
|
||||
activeBasePath: 'docs',
|
||||
label: 'Docs',
|
||||
position: 'left',
|
||||
},
|
||||
{to: 'news', label: 'News', position: 'left'},
|
||||
{
|
||||
href: 'https://github.com/ctrliq/warewulf',
|
||||
label: 'GitHub',
|
||||
position: 'right',
|
||||
},
|
||||
],
|
||||
},
|
||||
footer: {
|
||||
style: 'light',
|
||||
links: [
|
||||
{
|
||||
title: 'Docs',
|
||||
items: [
|
||||
{
|
||||
label: 'Getting Started',
|
||||
to: 'docs',
|
||||
},
|
||||
],
|
||||
},
|
||||
{
|
||||
title: 'Community',
|
||||
items: [
|
||||
{
|
||||
label: 'Slack',
|
||||
href: 'https://join.slack.com/t/hpcng/shared_invite/zt-ll5c3ofb-XhvMPbXUhTVrHlutQz2jbA',
|
||||
},
|
||||
{
|
||||
label: 'YouTube',
|
||||
href: 'https://www.youtube.com/channel/UCQbKq1vIffqRAMUDPfHcU0w',
|
||||
},
|
||||
],
|
||||
},
|
||||
{
|
||||
title: 'More',
|
||||
items: [
|
||||
{
|
||||
label: 'News',
|
||||
to: 'news',
|
||||
},
|
||||
{
|
||||
label: 'GitHub',
|
||||
href: 'https://github.com/ctrliq/warewulf',
|
||||
},
|
||||
],
|
||||
},
|
||||
],
|
||||
copyright: `Copyright © ${new Date().getFullYear()} Ctrl IQ, Inc. - All Rights Reserved.`,
|
||||
},
|
||||
},
|
||||
presets: [
|
||||
[
|
||||
'@docusaurus/preset-classic',
|
||||
{
|
||||
docs: {
|
||||
sidebarPath: require.resolve('./sidebars.js'),
|
||||
editUrl:
|
||||
'https://github.com/ctrliq/warewulf-docs/edit/master/',
|
||||
},
|
||||
blog: {
|
||||
showReadingTime: true,
|
||||
editUrl:
|
||||
'https://github.com/ctrliq/warewulf-docs/edit/master/blog/',
|
||||
routeBasePath: 'news',
|
||||
path: './news',
|
||||
},
|
||||
theme: {
|
||||
customCss: require.resolve('./src/css/custom.css'),
|
||||
},
|
||||
},
|
||||
],
|
||||
],
|
||||
};
|
||||
11
docs/news/2021-02-25-4.0.0.md
Normal file
11
docs/news/2021-02-25-4.0.0.md
Normal file
@@ -0,0 +1,11 @@
|
||||
---
|
||||
slug: 4.0.0
|
||||
title: 4.0.0
|
||||
author: Brian Clemens
|
||||
author_title: Solutions Architect @ Ctrl IQ
|
||||
author_url: https://github.com/brianclemens
|
||||
author_image_url: https://avatars.githubusercontent.com/u/13581364?s=400&v=4
|
||||
tags: [changelog, release]
|
||||
---
|
||||
|
||||
This is a placeholder for the announcement that will come with the first release of Warewulf v4
|
||||
34
docs/package.json
Normal file
34
docs/package.json
Normal file
@@ -0,0 +1,34 @@
|
||||
{
|
||||
"name": "warewulf-docs",
|
||||
"version": "0.0.0",
|
||||
"private": true,
|
||||
"scripts": {
|
||||
"docusaurus": "docusaurus",
|
||||
"start": "docusaurus start",
|
||||
"build": "docusaurus build",
|
||||
"swizzle": "docusaurus swizzle",
|
||||
"deploy": "docusaurus deploy",
|
||||
"serve": "docusaurus serve",
|
||||
"clear": "docusaurus clear"
|
||||
},
|
||||
"dependencies": {
|
||||
"@docusaurus/core": "2.0.0-alpha.70",
|
||||
"@docusaurus/preset-classic": "2.0.0-alpha.70",
|
||||
"@mdx-js/react": "^1.6.21",
|
||||
"clsx": "^1.1.1",
|
||||
"react": "^16.8.4",
|
||||
"react-dom": "^16.8.4"
|
||||
},
|
||||
"browserslist": {
|
||||
"production": [
|
||||
">0.5%",
|
||||
"not dead",
|
||||
"not op_mini all"
|
||||
],
|
||||
"development": [
|
||||
"last 1 chrome version",
|
||||
"last 1 firefox version",
|
||||
"last 1 safari version"
|
||||
]
|
||||
}
|
||||
}
|
||||
40
docs/sidebars.js
Normal file
40
docs/sidebars.js
Normal file
@@ -0,0 +1,40 @@
|
||||
module.exports = {
|
||||
someSidebar: {
|
||||
'About': [
|
||||
'about/introduction',
|
||||
'about/architecture',
|
||||
'about/security',
|
||||
'about/templating',
|
||||
],
|
||||
'Prerequisites': [
|
||||
'prerequisites/hardware',
|
||||
'prerequisites/software',
|
||||
],
|
||||
'Getting Started': [
|
||||
'getting-started/quickstart-el7',
|
||||
'getting-started/quickstart-el8',
|
||||
],
|
||||
'wwctl': [
|
||||
'wwctl/configure',
|
||||
'wwctl/container',
|
||||
'wwctl/controller',
|
||||
'wwctl/kernel',
|
||||
'wwctl/node',
|
||||
'wwctl/overlay',
|
||||
'wwctl/power',
|
||||
'wwctl/profile',
|
||||
'wwctl/ready',
|
||||
'wwctl/server',
|
||||
'wwctl/wwctl',
|
||||
],
|
||||
'Contributing': [
|
||||
'contributing/contributing',
|
||||
'contributing/documentation',
|
||||
'contributing/development-environment-kvm',
|
||||
'contributing/development-environment-vbox',
|
||||
],
|
||||
'Appendix': [
|
||||
'appendix/glossary',
|
||||
],
|
||||
},
|
||||
};
|
||||
25
docs/src/css/custom.css
Normal file
25
docs/src/css/custom.css
Normal file
@@ -0,0 +1,25 @@
|
||||
/* stylelint-disable docusaurus/copyright-header */
|
||||
/**
|
||||
* Any CSS included here will be global. The classic template
|
||||
* bundles Infima by default. Infima is a CSS framework designed to
|
||||
* work well for content-centric websites.
|
||||
*/
|
||||
|
||||
/* You can override the default Infima variables here. */
|
||||
:root {
|
||||
--ifm-color-primary: #229529;
|
||||
--ifm-color-primary-dark: #1f8625;
|
||||
--ifm-color-primary-darker: #1d7f23;
|
||||
--ifm-color-primary-darkest: #18681d;
|
||||
--ifm-color-primary-light: #25a42d;
|
||||
--ifm-color-primary-lighter: #27ab2f;
|
||||
--ifm-color-primary-lightest: #2cc235;
|
||||
--ifm-code-font-size: 95%;
|
||||
}
|
||||
|
||||
.docusaurus-highlight-code-line {
|
||||
background-color: rgb(72, 77, 91);
|
||||
display: block;
|
||||
margin: 0 calc(-1 * var(--ifm-pre-padding));
|
||||
padding: 0 var(--ifm-pre-padding);
|
||||
}
|
||||
94
docs/src/pages/index.js
Normal file
94
docs/src/pages/index.js
Normal file
@@ -0,0 +1,94 @@
|
||||
import React from 'react';
|
||||
import clsx from 'clsx';
|
||||
import Layout from '@theme/Layout';
|
||||
import Link from '@docusaurus/Link';
|
||||
import useDocusaurusContext from '@docusaurus/useDocusaurusContext';
|
||||
import useBaseUrl from '@docusaurus/useBaseUrl';
|
||||
import styles from './styles.module.css';
|
||||
|
||||
const features = [
|
||||
{
|
||||
title: 'Lightweight',
|
||||
imageUrl: 'img/logo.png',
|
||||
description: (
|
||||
<>
|
||||
Warewulf needs to do its job and stay out of the way. There should be no underlying system dependencies, changes or “stack” for the controller or worker nodes.
|
||||
</>
|
||||
),
|
||||
},
|
||||
{
|
||||
title: 'Simple',
|
||||
imageUrl: 'img/logo.png',
|
||||
description: (
|
||||
<>
|
||||
Warewulf is used by hobbyists, researchers, scientists, engineers and systems administrators. This means that Warewulf must be simple to use and understand.
|
||||
</>
|
||||
),
|
||||
},
|
||||
{
|
||||
title: 'Flexible',
|
||||
imageUrl: 'img/logo.png',
|
||||
description: (
|
||||
<>
|
||||
Warewulf is highly flexible and can address the needs of any environment– from a computer lab with graphical workstations, to under-the-desk clusters, to massive supercomputing centers providing traditional HPC capabilities to thousands of users.
|
||||
</>
|
||||
),
|
||||
},
|
||||
];
|
||||
|
||||
function Feature({imageUrl, title, description}) {
|
||||
const imgUrl = useBaseUrl(imageUrl);
|
||||
return (
|
||||
<div className={clsx('col col--4', styles.feature)}>
|
||||
{imgUrl && (
|
||||
<div className="text--center">
|
||||
<img className={styles.featureImage} src={imgUrl} alt={title} />
|
||||
</div>
|
||||
)}
|
||||
<h3>{title}</h3>
|
||||
<p>{description}</p>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
||||
function Home() {
|
||||
const context = useDocusaurusContext();
|
||||
const {siteConfig = {}} = context;
|
||||
return (
|
||||
<Layout
|
||||
title={`${siteConfig.title}`}
|
||||
description="Description will go into a meta tag in <head />">
|
||||
<header className={clsx('hero hero--primary', styles.heroBanner)}>
|
||||
<div className="container">
|
||||
<h1 className="hero__title">{siteConfig.title}</h1>
|
||||
<p className="hero__subtitle">{siteConfig.tagline}</p>
|
||||
<div className={styles.buttons}>
|
||||
<Link
|
||||
className={clsx(
|
||||
'button button--outline button--secondary button--lg',
|
||||
styles.getStarted,
|
||||
)}
|
||||
to={useBaseUrl('docs/')}>
|
||||
Get Started
|
||||
</Link>
|
||||
</div>
|
||||
</div>
|
||||
</header>
|
||||
<main>
|
||||
{features && features.length > 0 && (
|
||||
<section className={styles.features}>
|
||||
<div className="container">
|
||||
<div className="row">
|
||||
{features.map((props, idx) => (
|
||||
<Feature key={idx} {...props} />
|
||||
))}
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
)}
|
||||
</main>
|
||||
</Layout>
|
||||
);
|
||||
}
|
||||
|
||||
export default Home;
|
||||
37
docs/src/pages/styles.module.css
Normal file
37
docs/src/pages/styles.module.css
Normal file
@@ -0,0 +1,37 @@
|
||||
/* stylelint-disable docusaurus/copyright-header */
|
||||
|
||||
/**
|
||||
* CSS files with the .module.css suffix will be treated as CSS modules
|
||||
* and scoped locally.
|
||||
*/
|
||||
|
||||
.heroBanner {
|
||||
padding: 4rem 0;
|
||||
text-align: center;
|
||||
position: relative;
|
||||
overflow: hidden;
|
||||
}
|
||||
|
||||
@media screen and (max-width: 966px) {
|
||||
.heroBanner {
|
||||
padding: 2rem;
|
||||
}
|
||||
}
|
||||
|
||||
.buttons {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
}
|
||||
|
||||
.features {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
padding: 2rem 0;
|
||||
width: 100%;
|
||||
}
|
||||
|
||||
.featureImage {
|
||||
height: 200px;
|
||||
width: 200px;
|
||||
}
|
||||
0
docs/static/.nojekyll
vendored
Normal file
0
docs/static/.nojekyll
vendored
Normal file
BIN
docs/static/img/favicon.png
vendored
Normal file
BIN
docs/static/img/favicon.png
vendored
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
BIN
docs/static/img/logo.png
vendored
Normal file
BIN
docs/static/img/logo.png
vendored
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 51 KiB |
Reference in New Issue
Block a user