OpenShift Origin Architecture Overview 意訳[3/3]

自分が調べたついでのメモの後半部分。

このドキュメントをテキトー意訳。
https://openshift.redhat.com/community/wiki/architecture-overview

＊ほったらかしで忘れてたので、途中で公開＊

Logical views

StickShift

StickShift is the core API part of the OpenShift Origin platform. It provides all the basic API support necessary for creating a PaaS platform and developing cartridges. It consists of 3 parts:

StickShiftはOpenStack OriginのコアAPIの一つです。
これはPaaS環境の作成やカードリッジ開発に必要なサポートを提供する基本的なAPIです。
これは3つのパーツから構成されます。

1. Controller is a Rails Engine (plugin) which includes a REST API, business logic and state management for the PaaS platform. It also includes a set of plugin APIs for DNS management, authentication, data/state storage, and broker-node communications.

2. Node includes the basic set of APIs needed to manage gears, and applications component life cycles.

3. Common includes data structures that are used by the controller and node components.

1. コントローラーはPaaS環境のためのREST API、ビジネスロジック、状態管理を含んだRailsエンジン（プラグイン）です。

2. ノードはギアの管理とアプリコンポーネントのライフサイクルを管理に必要とされる基本的なAPIセットを含んでいます。

3. Commonはコントローラとノードから使われるデータ構造を含んでいます。

Proxy ports

Proxy ports allow gears to expose internal services for the purposes of load balancing or providing its services to related application gears.

Proxy ports はロードバランス、もしくはアプリケーションギアに関連したサービスを提供するため、内部サービスを外部へ公開することをギアへ許可する。

Each gear can allocate up to 5 proxy ports. These are exposed on a routable address so that a related gear can connect to them even if that gear exists on a separate node.

各ギアは5つのProxy portsを割当てることができる。ギアが異なるノード上に存在する場合でも、関連するギアはそれらに接続できるよう、ルーティング可能なアドレスが公開される。

Proxy ports are enabled by HAProxy running as a system service and configured to proxy raw TCP connections; as opposed to the HAProxy cartridge which provides web load balancing sevice. In the future, they will be the underlying mechanism which is used to provide TCP connections described by Application Descriptors.

Proxy ports are not directly accessible from outside the collection of nodes.

Proxy portsはノードコレクションの外部から直接アクセスすることはできない。

Gear filesystem layout

.├── git # Gears git repository. Initially populated by the web-framework cartridge
│ └── [APP_NAME].git
| |
# The hook directory is the only one owned by root to prevent users from modifying it
│ ├── hooks
| | |
| | |
│ │ └── pre-receive
# Post receive hook invokes the build and deployment
│ └── ... other git directories
└── [APP_NAME]
# CI directory is used by Jenkins to clone and build the application.
├── ci
# Control script to start/stop application when node is restarted
├── kraman3a_ctl.sh
├──
│ └──
├── data
│ └── ... ephemeral data storage
├── run
│ └── ... PID files for processes
├── logs
│ └── ... log files for all cartridges
├── sessions
│ └── ... application session information
├── tmp
│ └── ... application temporary data
├── repo -> runtime/repo
└── runtime
└── repo
# Platform support for dependency management for cartridges such as php which dont have their own
├── deplist.txt
|
├── ... deployed application code
└── README

Descriptors

Application Descriptors

This section describes how a user constructs an application descriptor to define the dependencies, scaling architecture, and connections for their applications.

このセクションではユーザが依存関係、スケールアーキテクチャ、アプリへの接続を定義する方法について記述します。

Terms:

Name: The name of the application (required)
Version: The version of the application (optional)
Requires: A list of dependencies. Either cartridge names or capabilities
Cartridge: A packaged set of components that work together to provide a certain capability
Component: Smallest piece of a software package which provides some functionality. Users don’t see below this level.
Connections: Specify that two components needs to talk to each other. Eg: PHP and Mysql are not directly related but need to talk to each other.
Group Override: Used to specify that user wants to unrelated cartridges to be grouped on the same gear. In essence, embedding them together. These components will scale together.
Gear: A unit of CPU, memory, disk-space on which components can run.

Simple descriptor:

Name: myapp
Version: 1.0
Requires: php-1.0, mysql, mongodb
Connections:
- php-1.0, mysql
- php-1.0, mongodb
Group override:
- php-1.0, mysql

The descriptor above describes an application named “myapp” which depends on php-1.0, mysql and mongodb. Php,Mysql and Php, Mongodb need to communicate with each other. Php and mysql run embedded on the same set of gears while Mongodb runs on its own set of gears.

この記述子は上記のphp-1.0, mysql, mongodbに依存した"myapp"と名前のアプリケーションを説明しています。PHP, MongoDBとPHP, MySQLを互いに通信できる必要があります。PHPとMySQLは同じギアセットに埋め込まれて実行され、MongoDBは独自のギア上で実行される。

Cartridge descriptors

This section describes how a partner/cartridge developer uses descriptors to specify the capabilities of their cartridge. Their view into the system is different for an application developer and they are exposed to more advanced features.

このセクションでは


Terms:

Version, Vendor, License: Informational meta data fields not used by the system directly.
Requires native: Native/Platform-specific package dependencies (RPM)
Provides: A list of capabilities provided by the cartridge
Profile: The cartridge can group components into profiles to provide different architectures for the same piece of software. Eg: Mysql may provide a master-master and master-slave profile.
Publishers: List of connection endpoint hooks which can be invoked to obtain information from the component. E.g. mysql cartridge could provide a jdbc endpoint which when invoked would provide a jdbc connection string.
Subscribers: List of connection endpoint hooks which can be invoked to provide information to the component. E.g. jboss cartridge could subscribe to a jdbc endpoint which when invoked and provided with a jdbc string would configure a datasource.
Connection types: Publishers and subscribers specify a connection type based on which they are linked to each other. The Cloud-SDK provides a few built-in types NET:TCP, NET:UNIX, FILESYSTEM etc.
Groups: Components are organized in Groups for provisioning. Each group is provisioned with a consistent gear type. All components within a group will be placed on the same set of gears.
ComponentRef: An entry under the groups which specified which components are part of the group.
Configure-Order: A configure order can be specified for the components in the cartridge and its dependencies.
Start-Order: A start order can be specified for the components in the cartridge and its dependencies.


Example descriptor:

Name: mysql-server
Version: 1.0
Native-Requires: mysql-server
Provides: mysql
Profiles:
simple:
Components:
master:
Provides:
jdbc-uri:
Type: NET:TCP:JDBC
master-master:
...
The descriptor above describes an cartridge named “mysql-server” which provides the mysql capability. It depends on the mysql-server RPM to install and run. It provides two profiles: simple and master-master. The simple profile has one component named “master” which provides a publisher of type “NET:TCP:JDBC”.

Connector Types

Each connection (publisher and subscriber) must specify a connection type. This type is a : separated string that indicates the data that will be provided or consumed. Cloud-SDK has some predefined types that can be subclassed to provide other new types.

NET:TCP - Provides hostname, port
NET:UNIX - Provides path to unix socket
FILESYSTEM - Provides path to resource on local filesystem
FILESYSTEM:SHARED - provides path to resource on cluster filesystem.

Connector Establishment

While configuring, starting and stopping components, the publisher connector hooks are invoked and the information for each component on each gear is passed to the subscribing connectors. Component to gear assignment: When the cartridge is used by an application, its components may be placed on the same or different set of gears depending on a few factors:

Components will be placed on the same gear if they are pare of the same cartridge and the cartridge descriptor requires them to be in the same group.
Components will be placed on the same set of gears if a connection is established between them that is of type NET:UNIX, FILESYSTEM or NET:TCP:INTERNAL
Components will be placed on the same set of gears if the cartridge or application descriptor has an entry in the group overrides field that requires them to be collocated.

Runtime resolution of application/cartridge descriptors

This section describes the details of how the Cloud-SDK uses descriptors to assemble an application and dependencies and assign them to gears.

Terms (Runtime state storage on broker): The runtime hierarchy is built during the elaboration phase using information from the application descriptor and cartridge descriptors

Component Instance - A component instance is created for each component described in the cartridges and application descriptors. It keeps account of the cartridge, profile and component name it is created from.
Group Instance - Similar to component instances, a group instance is created for each group described in the cartridge and application descriptors. It keeps track of the original cartridge and profile it came from. It also keeps track of cartridge instances and gears that are part of the group. All gears within the group are running the same set of components.
Gear -


Terms (Runtime models on node):

ApplicationContainer: Represents a gear on the node side of the Cloud-SDK.
UnixUser: Represents a unix user on the node side of the Cloud-SDK.


Descriptor Elaboration Descriptor elaboration happens in 2 basic steps. These steps may be combined if it is efficient to do so.

Resolve all dependencies and create the runtime structure of Component instances and Group instances.
Combine groups based on connections and grouping overrides.

Submitted by Mark Atwood on Fri, 04/27/2012 - 09:00