rtyler
/
deploydb
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
deploydb/doc/config.adoc

5.9 KiB
Raw Blame History

<html lang="en"> <head> </head>

#DeployDB Configuration

Configuration Details:

  1. There are two types of configurations: Launch-Configuration and Models-Configuration.

  2. Launch-Configuration:

    1. DeployDB is launched with this configuration provided in the YAML file.

    2. The YAML file is passed at the command line (Ref: Running the Server)

deploydb.launch.yml
    # Database specifics
    database:
      driverClass: org.h2.Driver
      user: nobody
      url: "jdbc:h2:./deployDB.example.db"

    # Models-Configuration directory (cannonical path)
    # YAML configuration files for models - services, environments, pipelines,
    # webhooks and promotions - should be stored in respective sub-directories
    configDirectory: config

    # Whoas library specifics
    whoas:
      queue:
        type: "com.github.lookout.whoas.InMemoryQueue"
        key: "queue"
        hostname: "localhost"
        port: 6379
      runnerType: "com.github.lookout.whoas.SequentialHookRunner"

    # Logging specifics
    logging:
      level: INFO
      loggers:
        org.hibernate.SQL: ALL

  1. Models-Configuration:

    1. When DeployDB is launched, it consumes Models-Configuration and creates model objects.

    2. The configuration driven models are Service, Environment, Pipeline, Promotion, Webhook, etc.

    3. These configuration driven models are used to create and manage Flows and Deployments (Ref: <<workflow.ad#DeployDB WorkFlow,WorkFlow)

    4. The Launch-Configuration provides the "configDirectory" path, a Models-Configuration directory path.

    5. YAML configurations for each Model are stored under the respective sub-directory.

      1. ${configDirectory} - base Models-Configuration directory path. E.g.

        • /etc/deploydb/config/

      2. ${configDirectory}/services/ - Directory path for Service Models. E.g.

        • /etc/deploydb/services/FunAsService.yml,

        • /etc/deploydb/services/AuditLogAsService.yml,

        • Services Configuration

      3. ${configDirectory}/pipelines/ - Directory path for Pipeline Models. E.g.

      4. ${configDirectory}/environments/ - Directory path for Environment Models. E.g.

      5. ${configDirectory}/promotions/ - Directory path for Promotion Models. E.g.

      6. ${configDirectory}/webhook/ - Directory path for Webhook Model (Note that ONLY 1 webhook file is allowed to represent global webhooks). E.g.

        • /etc/deploydb/webhook/global.yml

        • Webhook Configuration

Reloading Models-Configuration:

  1. The configuration for models, can be changed and reloaded while DeployDB is running.

  2. An admin task is available to reload configuration from the "configDirectory".

  3. A POST to "http://<server-host>:<port>/tasks/configReload" from admin app will invoke this task.

  4. Reloading a changed configuration would have no impact on the in-progress or verified deployments.

  5. Reading the configuration during DeployDB version upgrade should have no impact on the in-progress or verified deployments, if following rules are followed by the DeployDB developer:

    1. Do not change data type of the existing fields in Models (e.g. Service, Pipeline, etc)

    2. New fields can be added in Models, but do not make new fields mandatory

Models-Configuration Management:

  1. DeployDB consumes the Models-Configuration during launch or when its reloaded via the admin task

  2. The configuration for each model is saved in DB to protect extant deployments from change in configuration.

  3. The contents of DB record are as follows:

    +----+----------+----------+---------------+-------------+
| id | checksum | contents | ident         | type        |
+----+----------+----------+---------------+-------------+
| 1  | 0xdead   | <YAML>   | FunAsService  | Service     |
+----+----------+----------+---------------+-------------+
| 2  | 0xdead   | <YAML>   | devtoprod     | Pipeline    |
+----+----------+----------+---------------+-------------+
| 3  | 0xdead   | <YAML>   | integ         | Environment |
+----+----------+----------+---------------+-------------+
| 4  | 0xdead   | <YAML>   | jenkins-smoke | Promotion   |
+----+----------+----------+---------------+-------------+
| 5  | 0xdead   | <YAML>   | global        | Webhook     |
+----+----------+----------+---------------+-------------+
| 6  | 0xbeef   | <YAML>   | FunAsService  | Service     |
+----+----------+----------+---------------+-------------+
| 7  | 0xbeef   | <YAML>   | devtoprod     | Pipeline    |
+----+----------+----------+---------------+-------------+
| 8  | 0xbeef   | <YAML>   | integ         | Environment |
+----+----------+----------+---------------+-------------+
| 9  | 0xbeef   | <YAML>   | jenkins-smoke | Promotion   |
+----+----------+----------+---------------+-------------+
| 10 | 0xbeef   | <YAML>   | global        | Webhook     |
+----+----------+----------+---------------+-------------+

    1. checksum - of the base Models-Configuration directory. Remains constant for a given iteration of the Models-Configuration

    2. contents - of YMAL file in String format

    3. ident - identifier for the model

    4. type - type of model (e.g. Service, Pipeline, etc.)

    5. The contents of (checksum, ident, type) will form a unique key

    6. Thus, each change in configuration will create new DB records

    7. As shown in the table above: Rows 1 thr 5 were added on initial DeployDB launch. And rows 6 thr 10 were populated on reload after a config change.

  4. Impact on WorkFlow:

    1. When Flow is created, the checksum is stored in the Flow to associate the Models-Configuration with it.

    2. When subsequent triggers are executed on the Flow, it retrieves Models-Configuration from DB and uses it. This allows us to Models-Configuration to change while Flows and Deployments are being verified.

Last updated 2024-05-16 23:33:28 UTC
</html>