JS7 JobScheduler

Space shortcuts

Page tree

Versions Compared

Old Version 40

changes.mady.by.user Andreas Püschel

Saved on

compared with

New Version 41

changes.mady.by.user Andreas Püschel

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Object Mappings

Configuration Objects

...

Rollout Objects

JS7 configuration objects that independent from a specific environment (dev, test, prod) and that can be rolled out across environments include

...

Such objects can be managed with JS7 in a way that allows to re-use the objects - without any changes - across rollout environments such as dev, test, prod.

...

Local Objects

The following configuration objects typically hold values that are specific for an individual rollout environment (dev, test, prod) and therefore usually are added to a separate repository. Such objects should not be rolled out across environments.

...

Folders can be mapped to Git repositories managed by the same or by different Git servers like this:


Flowchart
USER1 [label="   UserUser: 1   1",fillcolor="lightskyblue"]
USER2 [label="   UserUser: 2   2",fillcolor="lightskyblue"]
USER3 [label="   UserUser: 3   3",fillcolor="lightskyblue"]

FOLDER1 [label="   FolderFolder: 1   1",fillcolor="white"]
FOLDER1a [label="   SubSub-folder: 1.1   1",fillcolor="white"]
FOLDER1b [label="   SubSub-folder: 1.2   2",fillcolor="white"]
FOLDER2 [label="   FolderFolder: 2   2",fillcolor="white"]
FOLDER3 [label="   FolderFolder: 3   3",fillcolor="white"]

REPOSITORY1REPOSITORY1L [shape="ellipse",label="   Git Repository: 1   1-local\njob resources etc.",fillcolor="orangedarkolivegreen1"]
REPOSITORY2REPOSITORY1R [shape="ellipse",label="   Git Repository: 2   1-rollout\nworkflows etc.",fillcolor="orangedarkolivegreen1"]
REPOSITORY3REPOSITORY2L [shape="ellipse",label="   Git Repository: 3   2-local\njob resources etc.",fillcolor="orangedarkolivegreen1"]

USER1 -> FOLDER1 [label="  can access  "]
USER2 -> FOLDER1 [label="  can access  "]
USER2 -> FOLDER2 [label="REPOSITORY2R [shape="ellipse",label="Repository: 2-rollout\nworkflows etc.",fillcolor="darkolivegreen1"]
REPOSITORY3L [shape="ellipse",label="Repository: 3-local\njob resources etc.",fillcolor="darkolivegreen1"]
REPOSITORY3R [shape="ellipse",label="Repository: 3-rollout\nworkflows etc.",fillcolor="darkolivegreen1"]

USER1 -> FOLDER1 [label="  can access  "]
USER3USER2 -> FOLDER3FOLDER1 [label="  can access  "]

FOLDER1USER2 -> FOLDER1aFOLDER2 [label="  includescan access  "]
FOLDER1USER3 -> FOLDER1bFOLDER3 [label="  includescan access  "]

FOLDER1 -> REPOSITORY1FOLDER1a [label="  maps toincludes  "]
FOLDER2FOLDER1 -> FOLDER1b [label="  includes  "]
FOLDER1a -> REPOSITORY2REPOSITORY1L [label="  maps to  "]
FOLDER3FOLDER1a -> REPOSITORY3REPOSITORY1R [label="  maps to  "]

The mapping of folder objects to repositories implies


FOLDER1b -> REPOSITORY1L [label="  maps to  "]
FOLDER1b -> REPOSITORY1R [label="  maps to  "]

FOLDER2 -> REPOSITORY2L [label="  maps to  "]
FOLDER2 -> REPOSITORY2R [label="  maps to  "]
FOLDER3 -> REPOSITORY3L [label="  maps to  "]
FOLDER3 -> REPOSITORY3R [label="  maps to  "]


The mapping of folder objects to repositories implies

  • user access:
    • users with JS7 access permissions to manage folders and to access
    user access:
    • users with JS7 access permissions to manage folders and to access the Git repository can manage configuration objects in JOC Cockpit and can commit, push, pull configuration objects to/from Git,
    • users with JS7 access permissions to manage folders but without access to the Git repository can manage configuration objects in JOC Cockpit and can commit, push, pull configuration objects to/from Git,
    • users with JS7 access permissions to manage folders but without access to the Git repository can manage configuration objects in JOC Cockpit,
    • users with JS7 access permissions to view folders do not require Git access.
  • folder usage:
    • if a single Git repository should be used then all folders have to be available from a single root folder,
    • for use with a number of Git repositories each folder maps to a different repository,
    • folders can remain without Git integration for local management and deployment.

...

  • git-checkout
    • checks out a specific branch or tag from the Git repository to the local repository
  • git-clone
    • initially clones a Git repository to a local repository
  • git-pull
    • pulls recent changes from the Git repository to the local repository

...

JOC Cockpit

...

REST Web Service API Operations

The transfer synchronization of configuration objects between the JOC Cockpit database and the repositories are managed by the JS7 JOC REST Web Service API.

The following REST Web Service operations are available:

  • ./inventory/repository/read
    • reads file tree of the local repositories filesystem folderrepository file system folder and updates the JOC Cockpit database
  • ./inventory/repository/store
    • stores a set of configuration objects from the JOC Cockpit database to the filesystem file system folder of the local repository
  • ./inventory/repository/delete
    • deletes a set of configuration objects from the filesystem file system folder of the local repository
  • ./inventory/repository/update
    • adds or updates a set of configuration objects in the JOC Cockpit database with the configuration objects from the local repositories filesystem file system folder

Use Cases

Single Client - Multiple Repositories (dev, test, prod)

...

  • Architecture
    • A dedicated JOC Cockpit instance is used with Controller and Agents for each rollout environment such as dev, test, prod.
    • A Git repository is used per folder and per rollout environment (dev, test, prod), each JOC Cockpit instance is acting on a specific repository per rollout environment.
    • The Git repository is used to hold a copy of JS7 configuration objects and, depending on the rollout environment, to create versions of JS7 configuration objects.
  • Users
    • All users act in the same JOC Cockpit instance of the respective rollout environment that is a single client to the Git server.
    • Changes to the Git repositories are performed by the users' individual accounts and are added to the remote repositories.
  • Rollout
    • Deployments are performed from a single source (JOC Cockpit) to each Controller and Agents per rollout environment (dev, test, prod).
    • The Git repositories are used to checkout branches and to rollout JS7 configuration objects to different Controllers and Agents, such as dev => test => prod.
    • The Git repository can be used to fallback to previous versions of configuration objects, however, only one version is available with a given JOC Cockpit instance at a given point in time.
    • After an update of configurations objects in a given JOC Cockpit instance the updated configuration objects have to be deployed anew.

Repositories marked as "env" are specific for an environment and are excluded from rollout. Repositories marked as "rollout" are environment-independent and are forwarded across scheduling environments.

    • Controllers and Agents, such as dev => test => prod.
    • The Git repository can be used to fallback to previous versions of configuration objects, however, only one version is available with a given JOC Cockpit instance at a given point in time.
    • After an update of configurations objects in a given JOC Cockpit instance the updated configuration objects have to be deployed anew.

Repositories marked as "env" are specific for an environment and are excluded from rollout. Repositories marked as "rollout" are environment-independent and are forwarded across scheduling environments.


Flowchart
USER1a [label="  User: 1a  ",fillcolor="lightskyblue1"]
USER1b [label="  User: 1b  ",fillcolor="lightskyblue1"]
USER2 [label="  User: 2  ",fillcolor="lightskyblue2"]
USER3 [label="  User: 3  ",fillcolor="lightskyblue3"]

JOC1 [label="  JOC Cockpit: dev  ",fillcolor="lightskyblue1"]
JOC2 [label="  JOC Cockpit: test  ",fillcolor="lightskyblue2"]
JOC3 [label="  JOC Cockpit: prod  ",fillcolor="lightskyblue3"]

FOLDER1 [label="  Folder: 1 (dev)  ",fillcolor="white"]
FOLDER2 [label="  Folder: 1 (test)  ",fillcolor="white"]
FOLDER3 [label="  Folder: 1 (prod)  ",fillcolor="white"]

DATABASE1 [shape="ellipse",label="  Database: dev  ",fillcolor="lightskyblue1"]
DATABASE2 [shape="ellipse",label="  Database: test  ",fillcolor="lightskyblue2"]
DATABASE3 [shape="ellipse",label="  Database: prod  ",fillcolor="lightskyblue3"]

# GIT [label="Git Server",fillcolor="orange"]
REPO1ENV
Flowchart
USER1a [label="   User: 1a   ",fillcolor="lightskyblue"]
USER1b [label="   User: 1b   ",fillcolor="lightskyblue"]
USER2 [label="   User: 2   ",fillcolor="lightskyblue"]
USER3 [label="   User: 3   ",fillcolor="lightskyblue"]

JOC1 [label="   JOC Cockpit: dev   ",fillcolor="lightskyblue"]
JOC2 [label="   JOC Cockpit: test   ",fillcolor="lightskyblue"]
JOC3 [label="   JOC Cockpit: prod   ",fillcolor="lightskyblue"]

FOLDER1 [label="   Folder: 1 (dev)   ",fillcolor="white"]
FOLDER2 [label="   Folder: 1 (test)  ",fillcolor="white"]
FOLDER3 [label="   Folder: 1 (prod)   ",fillcolor="white"]

DATABASE1 [shape="ellipse",label="     Database: dev     ",fillcolor="lightskyblue"]
DATABASE2 [shape="ellipse",label="     Database: test     ",fillcolor="lightskyblue"]
DATABASE3 [shape="ellipse",label="     Database: prod     ",fillcolor="lightskyblue"]

# GIT [label="Git Server",fillcolor="orange"]
REPO1ENV [label="Repository: dev env",fillcolor="darkolivegreen1"]
REPO1ROL [label="Repository: dev rollout",fillcolor="darkolivegreen1"]
REPO2ENV [label="Repository: test env",fillcolor="darkolivegreen2"]
REPO2ROL [label="Repository: test rollout",fillcolor="darkolivegreen2"]
REPO3ENV [label="Repository: prod env",fillcolor="darkolivegreen3"]
REPO3ROL [label="Repository: prod rollout",fillcolor="darkolivegreen3"]

# BRANCHES1R [shape="ellipse",label="Branches: env devRepository: 1-dev-local\njob resources etc.",fillcolor="darkolivegreen1"]
#REPO1ROL BRANCHES1I [shape="ellipse",label="BranchesRepository: 1-dev-rollout\nworkflows devetc.",fillcolor="darkolivegreen1"]
#REPO2ENV BRANCHES2R [shape="ellipse",label="Branches: env testRepository: 1-test-local\njob resources etc.",fillcolor="darkolivegreen2"]
#REPO2ROL BRANCHES2I [shape="ellipse",label="BranchesRepository: 1-test-rollout\nworkflows testetc.",fillcolor="darkolivegreen2"]
# BRANCHES3RREPO3ENV [shape="ellipse",label="Branches: env prodRepository: 1-prod-local\njob resources etc.",fillcolor="darkolivegreen3"]
#REPO3ROL BRANCHES3I [shape="ellipse",label="BranchesRepository: 1-prod-rollout\nworkflows prodetc.",fillcolor="darkolivegreen3"]

{ rank = same; JOC1 -> DATABASE1 }
{ rank = same; JOC2 -> DATABASE2 }
{ rank = same; JOC3 -> DATABASE3; }

JOC1 -> FOLDER1 
FOLDER1 -> REPO1ENV [label="Commit/Push\nPull  commit/push\npull  "]
FOLDER1 -> REPO1ROL [label="Commit/Push\nPull  commit/push\npull  "]

JOC2 -> FOLDER2
FOLDER2 -> REPO2ENV [label="Commit/Push\nPull  commit/push\npull  "]
FOLDER2 -> REPO2ROL [label="Commit/Push\nPull  commit/push\npull  "]

JOC3 -> FOLDER3 
FOLDER3 -> REPO3ENV  [label="Commit/Push\nPull  commit/push\npull  "]
FOLDER3 -> REPO3ROL  [label="Commit/Push\nPull  commit/push\npull  "]

REPO1ROL -> REPO2ROL [label="  copy  "]
REPO2ROL -> REPO3ROL [label="  copy  "]

# REPO1 -> GIT
# REPO2 -> GIT
# REPO3 -> GIT

USER1a -> JOC1;
USER1b -> JOC1;
USER2 -> JOC2;
USER3 -> JOC3;

Repository Operations

  • management
  • versioning
  • rollout

...