oeDeploy User Guide ​

1 Introduction ​

1.1 About oeDeploy ​

oeDeploy (oedp) is a rapid application deployment platform offering these key features:

1. Plugin library: Enables quick application installation by allowing apps to be adapted as oedp plugins following basic specifications, with oedp handling capability parsing and execution.
2. Automated ansible conversion: Transforms manual installation procedures into ansible playbooks by analyzing configured installation steps.
3. One-click deployment: Supports seamless integration of applications with existing one-click or ansible-based installation methods.
4. Distribution system: Provides one-click application deployment to target hosts.
5. Ansible integration: Leverages ansible for core platform functionality.

1.2 oeDeploy Components ​

The oedp tool comprises:

• oedp webUI: (Coming soon) Designed to streamline operations and reduce the learning curve, converting user configurations into CLI commands for deployment tasks.
• oedp CLI: Serves as an integration platform that orchestrates plugin operations and provides feedback, offering advanced customization options for power users.
• oedp plugins: Modular components that deliver specific deployment functions like installation, uninstallation, and environment cleanup.

1.3 Download and Installation ​

oedp supports both x86_64 and aarch64 architectures.

You can download the oedp package and install it using yum install -y oedp-xxx.rpm or dnf install -y oedp-xxx.rpm.

1.4 Command List ​

• oedp init <plugin>: Initialize a plugin.
  • -p|--project <path>: Required, specify the initialization path.
  • -l|--local <path>: Optional, specify a path as a local repository.
  • -f|--force: Optional, force overwrite a path. If the path exists, all files will be deleted before initialization.
• oedp list: List available plugins.
  • -l|--local <path>: Optional, specify a path as a local repository.
• oedp info: View detailed project information.
  • -p|--project <path>: Optional, specify a project. The current path is used if no path is specified.
• oedp run <action>: Execute a project method.
  • <action>: Method name available for plugin (can be queried via oedp info).
  • -p|--project <path>: Optional, specify a project. The current path is used if no path is specified.
• oedp check: (Coming soon) Check a project.
  • -p|--project <path>: Optional, specify a project. The current path is used if no path is specified.

1.5 File Paths ​

• /var/oedp/log/: log file directory
• /var/oedp/plugin/: plugin cache directory
• /usr/lib/oedp/src/: source code directory
• /etc/oedp/config: configuration file directory

2 Deployment Guide ​

This section demonstrates the deployment process using Kubernetes 1.31.1 as an example.

2.1 Obtaining the Deployment Plugin ​

Note: The following feature is not yet available.

Run this command to install the plugin and initialize a project:

oedp init kubernetes-1.31.1 -p .

Current workaround:

Manually download the plugin package kubernetes-1.31.1.tar.gz.

Extract the package in the current working directory to obtain the kubernetes-1.31.1/ directory.

2.2 Viewing Plugin Information ​

Use the info command to display detailed plugin information:

oedp info -p kubernetes-1.31.1

2.3 Node Configuration ​

Edit the configuration file to specify node parameters:

vim kubernetes-1.31.1/config.yaml

Note:

• SSH authentication supports both password and key-based methods. The password is not required for key-based login.
• Ensure that the control node can use SSH to access all target hosts and that all target hosts are in the known_hosts file on the control node. (Achieve this by manually accessing each target host through SSH)

2.4 Deployment Execution ​

Start the automated deployment process:

oedp run install -p kubernetes-1.31.1

Uninstall Kubernetes:

oedp run delete -p kubernetes-1.31.1

3 Plugin Development Guide ​

3.1 Overview of oedp Plugins ​

oedp plugins enable automated deployment by translating complex workflows into Ansible-based automation. These plugins support various deployment actions, such as installation, uninstallation, and environment cleanup, each mapped to an Ansible playbook. To streamline usability and maintenance, all plugin configurations are centralized.

3.2 Directory Structure ​

Developers must adhere to the following directory structure:

{plugin_name}
|-- main.yaml
|-- config.yaml
`-- workspace/

Naming rules for plugin_name:

• It must include the software name and version.
• The formats must be either of the following:
  • {name}-{version}
  • {name}-{version}-xxx
• Example: A Kubernetes 1.31.1 deployment plugin can be named kubernetes-1.31.1, kubernetes-1.31.1-20240101, or kubernetes-1.31.1-offline-20240101.

The following uses a Kubernetes 1.31.1 deployment plugin to demonstrate the YAML structure.

3.2.1 main.yaml ​

main.yaml records essential plugin information, such as its name, version, description, and actions. When a user runs the oedp info command, the oedp tool reads and parses this file to display its details.

The action field should be a dictionary (key-value map). Each key serves as an action name, and its corresponding value contains specific action details.

The action details are provided as a dictionary. The description field explains the action and is shown to the user when oedp info is executed. The tasks field lists the specific steps for the action. When the action is executed, these steps are performed sequentially.

Within each step, developers should specify the path to playbook that needs to be run. If required, the path to a variables file can also be specified under vars. All paths are relative to the workspace. Additionally, scope can be defined to specify the host group for step execution, defaulting to all.

name: kubernetes
version: 1.31.1
description: install kubernetes 1.31.1
action:
  install:
    description: install kubernetes
    tasks:
      - name: install kubernetes
        playbook: init-k8s.yml
        vars: variables.yml
        scope: all
  delete:
    description: delete kubernetes
    tasks:
      - name: delete kubernetes
        playbook: delete-k8s.yml
        vars: variables.yml
        scope: all
  clean:
    description: clean cache files
    tasks:
      - name: clean cache files
        playbook: clean-k8s.yml
        scope: all

The directory structure within workspace/ for the plugin described above is:

workspace
|-- roles
|   `-- ...
|-- init-k8s.yml
|-- delete-k8s.yml
|-- clean-k8s.yml
|-- variables.yml
`-- ...

3.2.2 config.yaml ​

config.yaml serves as the user configuration file within the plugin, primarily containing host group configurations and other global settings. It adheres to Ansible inventory file configuration rules and can be directly used as an inventory when Ansible playbooks are executed.

Plugin developers should ensure all configuration items are consolidated within this file.

all:
  children:
    masters:
      hosts:
        Master1:
          ansible_host: 192.168.10.1
          ansible_port: 22
          ansible_user: root
          ansible_password: password
          architecture: amd64
          oeversion: 24.03-LTS
    workers:
      hosts:
        Worker1:
          ansible_host: 192.168.10.2
          ansible_port: 22
          ansible_user: root
          architecture: arm64
          oeversion: 22.03-LTS
        Worker2:
          ansible_host: 192.168.10.3
          ansible_port: 22
          ansible_user: root
          architecture: amd64
          oeversion: 22.03-LTS
  vars:
    init_cluster_force: "true"
    kubernetes_version: 1.31.1
    service_cidr: 10.96.0.0/16
    pod_cidr: 10.244.0.0/16
    pause_image: registry.k8s.io/pause:3.10
    calico_version: 3.28.2
    certs_expired: 3650
    has_deployed_containerd: "false"

3.3 Plugin Packaging ​

To distribute the plugin to users, the plugin must be packaged as {plugin_name}.tar.gz. The name of the compressed file must match the internal directory name, and decompression should generate exactly one directory, as in:

kubernetes-1.31.1.tar.gz
`-- kubernetes-1.31.1
    |-- main.yaml 
    |-- config.yaml
    `-- workspace/