【2018年9月13日開催】 実例紹介! Ansible自動化セミナー開催

Ansible自動化セミナー開催決定!

2018年9月13日に「実例紹介!3社共催 Ansible自動化セミナー」を三菱総研DCS様、レッドハット様と3社共同で開催します。

自動化導入の実例として三菱総研DCS様より「FINEQloud × AnsibleTower クラウド運用自動化への挑戦」を講演いただきます。そして、レッドハット様からはInfrastructure as Code / DevOpsをテーマにAnsible TowerとRed Hat OpenShiftの最新事例を紹介いただきます。今注目の技術に関する実例を知ることができるなりますので、ご興味をお持ちの方はぜひお誘い合わせの上でご登録をお願いいたします。

※セミナーへのご参加には、以下のURLから事前のご来場登録が必要となります。
「実例紹介!3社共催 Ansible自動化セミナー」
<URL> https://sios.secure.force.com/webform/SeminarDetail?id=701100000012QnNAAU

 

共催 三菱総研DCS株式会社 / レッドハット株式会社 / サイオステクノロジー株式会社
日時 2018年09月13日 (木) 15:30~18:15 受付開始 15:00
対象者 エンドユーザー企業及びSIerのOSSシステム管理者、情報システム部門、システムアーキテクト
講演内容 プログラム 15:00~

受付 15:30~15:40 オープニング

15:40~16:10  サイオステクノロジー講演

企業に求められる自動化
~現場の声から知る自動化の課題~

講師: IaC活用研究会員  サイオステクノロジー株式会社   イノベーティブソリューション事業企画部
村田 龍洋

16:10~16:55  三菱総研DCS講演

FINEQloud × AnsibleTower クラウド運用自動化への挑戦
~システム運用からのヒトの解放とガバナンス強化~

講師: 三菱総研DCS株式会社 技術推進事業本部 技術企画統括部事業企画グループ
西岡 裕子

16:55~17:05 休憩

17:05~17:50  レッドハット講演

Infrastructure as Code / DevOpsにおけるレッドハットの最新事例紹介
~自動化プラットフォーム Ansible TowerからエンタープライズKubernetes OpenShiftまで~

講師: レッドハット株式会社 プロダクトソリューション本部  クラウドビジネスデベロップメント  中村 誠

17:50~18:00  サービス紹介

18:00~18:15  Q&A クロージング

参加費 無料
締め切り 2018年09月13日
定員 80名
会場 レッドハット株式会社
東京都渋谷区恵比寿4-1-18 恵比寿ネオナート 3F
<アクセス> JR恵比寿駅 東口改札出口より徒歩2分
セミナー登録URL  https://sios.secure.force.com/webform/SeminarDetail?id=701100000012QnNAAU

コンテナアプリケーションプラットフォーム「Red Hat OpenShift」を触ってみた Vol.4

【第4回】本記事では、コンテナアプリケーションプラットフォーム「Red Hat OpenShift」(以降、「OpenShift」と記載)を触ってみたエンジニアより、その概要と感想をご紹介したいと思います。

はじめに

本連載はサイオスグループのキーポート・ソリューションズの開発プログラマーが、コンテナアプリケーションプラットフォーム「Red Hat OpenShift」(以降、「OpenShift」と記載)を触ってみて、その概要と感想をご紹介します。(普段はアプリケーション開発に従事しているため、OS、ミドルウェアについては決して得意ではない筆者です。)

第4回目のテーマは「運用」。開発ベンダーの立場からアプリケーション環境を管理、運用するにあたり、OpenShiftを利用することにより、どのようなメリットがあるのか、どのような不明点や課題があるのかを考察しようという主旨です。

運用におけるよくある問題点

開発ベンダーとしてアプリケーション開発に従事している弊社が、お客様と開発プロジェクトを進める際に、色々と問題点があります。

特に弊社は金融機関のお客様との取引が多いのですが、下記のような問題点は顕著に見られます。

・まず、開発プロジェクトにおいてアプリケーション開発とインフラ環境構築は多くの場合、別の担当者が実施

するため、アプリケーションとインフラの線引きが明確にされており、壁を感じることが多々あります。

この壁は運用フェーズに移行してからも残ることが多く、運用担当者はアプリケーション担当、インフラ担当

それぞれから引き継いだ内容を元に運用を行います。

そのため、どうしても申請や手続きが煩雑、かつ、慎重となり、対応が遅くなってしまいます。

・インフラ環境をスケールアウトしたいと思った場合、構成によってはミドルウェアやアプリケーションにまで

影響が及ぶこともあり、また、スケールアウト自体も運用監視や障害対応手順などの見直しも必要となり、

かなり負荷のかかる作業になってしまうことが多々あります。

運用時に便利な機能と手順

OpenShiftでは、テンプレートを事前に用意しておくことで、容易に外部の環境を移行したり新規環境を構築することができます。

また、ビルド&デプロイといった開発担当者に依存せざるを得ない作業も、コンフィグ設定しておくことで自動化することができます。

今回は、以下の作業について検証してみました。

 

①    OpenShift外にある既存のDockerコンテナをOpenShift内に移行する。

②    Podのオートスケール

③    ビルド&デプロイの自動化

 

本ブログでは上記のうち、①・②の手順をご紹介したいと思います。

①   OpenShift外にある既存のDockerコンテナをOpenShift内に移行する。

registry-consoleを開き今回使いたいUbuntu用のイメージストリームを作っておく。

registry-consoleにログインしてプロジェクト「openshift」を選択し、「新規イメージストリーム」からイメージストリームを作成する。

イメージがプルされているのを確認。

githubにプロジェクトを作成し、必要なファイルを配置する。

Dockerfileはトップに配置し、Webサーバ用のコンテンツをhtmlフォルダ以下に置いておく。

(基本的にはローカルでDockerコンテナをビルドするときと同じフォルダ構成にする)

その他Dockerコンテナに必要なファイルがあればそれも置いておく。(今回はApache起動用のrun-apache2.sh)

 

Dockefileを修正する。

※「#ベースイメージの指定」にて、イメージの取得元を外部Docker Hubのパスから内部Openshiftのパスに

変更する。

# ベースイメージの指定

FROM openshift/ubuntu:14.10

 

# 作者情報

MAINTAINER keyportsolutions XXXXXXXXX@keyportsolutions.com

 

# 必要なファイルのインストール

USER root

RUN sudo sed -i -e ‘s;utopic;trusty;g’ /etc/apt/sources.list

RUN apt-get -o Acquire::http::proxy=”http://proxy.fiosys.co.jp:8080″ update

RUN apt-get -o Acquire::http::proxy=”http://proxy.fiosys.co.jp:8080″ -y install apache2

COPY ./html /var/www/html/

COPY ./run-apache2.sh /tmp/

RUN chmod 755 /tmp/run-apache2.sh

EXPOSE 80

CMD /tmp/run-apache2.sh

Openshift用のテンプレートを作成する。

※下記yaml形式の場合インデントを厳密にみるので注意すること。

apiVersion: v1
items:
– apiVersion: V1
kind: ImageStream
metadata:
name: ubuntu-apache
– apiVersion: V1
kind: BuildConfig
metadata:
annotations:
description: Ubuntu Apache test
labels:
app: ubuntu-apache
name: ubuntu-apache
spec:
output:
to:
kind: ImageStreamTag
name: ubuntu-apache:latest
source:
git:
uri: https://github.com/アカウント名/openshift-test1.git
type: Git
strategy:
dockerStrategy:
from:
kind: ImageStreamTag
name: ubuntu:14.10
namespace: openshift
type: Docker
triggers:
– type: ImageChange
– type: ConfigChange
– apiVersion: V1
kind: DeploymentConfig
metadata:
annotations:
description: Ubuntu Apache test
labels:
app: ubuntu-apache
name: ubuntu-apache
spec:
template:
metadata:
labels:
name: ubuntu-apache
spec:
containers:
– name: ubuntu-apache-latest
image: ubuntu-apache:latest
ports:
– containerPort: 80
protocol: TCP
replicas: 1
selector:
name: ubuntu-apache
triggers:
– type: ImageChange
imageChangeParams:
automatic: true
containerNames:
– ubuntu-apache-latest
from:
kind: ImageStreamTag
name: ubuntu-apache:latest
– type: ConfigChange
– apiVersion: V1
kind: Service
metadata:
annotations:
description: Ubuntu Apache test
labels:
app: ubuntu-apache
name: ubuntu-apache
spec:
ports:
– name: web
port: 80
targetPort: 80
selector:
name: ubuntu-apache
– apiVersion: V1
kind: Route
metadata:
name: ubuntu-apache
spec:
host: ubuntu-test.dev.openshift.fiosys.co.jp
to:
kind: Service
name: ubuntu-apache
kind: List
metadata: {}

作ったテンプレートのyamlファイルを元にビルド&デプロイする。

Create Projectボタンを押下して新プロジェクト作成画面へ。

必要項目を入力してプロジェクトを作成。

今回は自作のテンプレートから作成するので「Import YAML / JSON」タブをクリック。

先ほど作成したテンプレートを貼りつける。

Createを押下すると文法的にOKならビルド&デプロイが開始される。

ビルド&デプロイが完了。

リンクから自分が配置したindex.htmlにアクセスできることを確認。

②   Podのオートスケール

※オートスケールを設定するには、Metrics Plugin が有効になっていることが前提となります。

 

プロジェクトの画面でApplication→Deploymentをクリックしてデプロイメントの一覧を表示する。

対象のデプロイメントの名前をクリック。

Configurationをクリック。

 

Actions→Edit Resource Limitsを選択する。

 

CPU使用率の上限を設定しておく。(今回は1コアまで)

設定後再デプロイされるので完了後もう一度デプロイメントの画面にもどる。

Add Autoscalerをクリック。

ポッド数とオートスケールされる条件となるCPU使用率を入力するとオートスケールが追加される。

運用を効率化するには

上記でご紹介したOpenShift のテンプレートによる環境構築、オートスケール、ビルド&デプロイの自動化などにより、前述の問題点は解決できるのではないかと感じました。

まず、アプリケーションとインフラの壁の問題については、テンプレートによる環境構築の簡易化、およびビルド&デプロイの自動化により、インフラ担当者や開発担当者でなければ作業ができないという状況を変えることができます。

また、OpenShiftという共通の基盤を使用することにより手順も一元化されるため、運用作業における専門性が軽減されます。

申請や手続き等が煩雑になる理由として、作業に専門性が必要になることや、手作業が多々必要となることが挙げられますので、自動化により申請や手続き等も簡易化し、迅速な対応が可能となります。

また、Redhat Ansibleと組み合わせることにより、パッチを適用しテストを実施するところまでを含めた自動化なども可能にできそうなので、さらなる効率化、自動化が図れそうです。

 

次に、やはりオートスケール機能については、かなり有効な機能だと思います。

前述の通り、インフラ環境のスケールアウトはかなり作業負荷が大きいものなので、オートスケールにより許容する範囲内でのスケールアウトは全てOpenShiftに任せてしまうことができます。

これは単にスケールアウトにかかる作業の軽減だけではなく、運用監視についても大きな改善をもたらすと考えられます。

今なお多い運用監視方法としては、CPU、メモリ、DISKなどの使用率を常時監視し、一定の使用率を超えたらアラートを鳴動させ検知するというものですが、オートスケールとなることで少なくともOpenShift内に設置されているシステム環境ごとの監視という点においては、リソースの枯渇を防ぐための監視ではなく、システムのパフォーマンスを最適にするための監視として運用することができます。

これにより、運用監視にかかる作業コストは、よりサービスレベルを維持、向上させるための高度な作業に集中させることができますし、運用コストも大幅に軽減されるのではないかと思います。

それ以外にも上述のようなOpensShiftの機能を活用すれば、例えば、本番環境と同等の開発環境を用意しておくことにより、システム変更が発生した場合に、開発環境にて更新されたものをそのまま本番環境に反映するようなことも可能です。

うまく機能を活用することでテストなど手作業に依存しがちな作業も大幅に軽減することができますし、かなり有効だなと思います。

さいごに

今回、環境構築、開発、運用という観点でOpenShiftを実際に触ってみて、その機能を検証してみました。

正直検証を始める前は、OpensShiftがどのようにDevOpsにつながっていくのか、資料上ではなんとなく理解はしているもののあまり明確なイメージはできていませんでした。

特に、環境構築については、インフラ知識が乏しかったこともあり、かなり苦戦し、色々な勘違いや認識不足もあったため、やはりベースとなる知識が必要であると感じました。

 

開発という観点では、Gitとの連携やビルド&デプロイが非常に簡単に実行できることにちょっとした感動を覚えました。

上述の通り、インフラ知識が不足しているため、OpenShiftによりIPアドレスなどOSレベルの挙動を意識する必要がないことも、開発を実施する上で非常に楽であると実感しました。

また、運用という観点では、特に弊社のようなアプリケーション開発をやっている立場としては、正直どうしても「インフラは担当外だ」、「運用は担当外だ」という思考になりがちで、それが壁になってしまっているために、「DevOps」のイメージがいまいち明確に沸いてこないところがありました。(これは反省すべき点です。)

しかし、実際に触ってみることで、そのような専門外の部分の処理も含めてOpenShiftが実行してくれることで、インフラとか運用とかあまり意識しなくてもいいということを実感することができ、壁が取れそうな気がしています。

 

昨今DevOpsというキーワードをよく目にしますが、まだまだ身近なものだと理解している人は少ないようにも思えますが、それはきっとインフラ担当・開発担当・運用担当の間に距離感や壁のようなものがあるからなのかもしれません。

OpenShiftがそのような壁を取り払ってくれるのではないかと、今回の検証を通して感じました。

コンテナアプリケーションプラットフォーム「Red Hat OpenShift」を触ってみた Vol.3

【第3回】本記事では、コンテナアプリケーションプラットフォーム「Red Hat OpenShift」(以降、「OpenShift」と記載)を触ってみたエンジニアより、その概要と感想をご紹介したいと思います。

はじめに

本連載はサイオスグループのキーポート・ソリューションズの開発プログラマーが、コンテナアプリケーションプラットフォーム「Red Hat OpenShift」(以降、「OpenShift」と記載)を触ってみて、その概要と感想をご紹介します。(普段はアプリケーション開発に従事しているため、OS、ミドルウェアについては決して得意ではない筆者です。)

第3回目のテーマは「開発」。開発ベンダーの立場から社内にてアプリケーション開発を行うにあたり、OpenShiftを利用することにより、どのようなメリットがあるのか、どのような不明点や課題があるのかを洗い出そうという主旨です。

アプリケーション開発における問題点

普段アプリケーション開発に従事している弊社では、以下のような問題点を抱えています。

   ・保守、開発しているシステムが多数あるが、システムごとに開発環境を用意しており、OS、M/W、

フレームワーク、開発言語などさまざまで、環境が乱立している。

 ・システムごとに環境や手順が異なるため、ナレッジを共有できず属人化している。

(サーバ環境だけでなく、ローカル端末の開発環境も様々で、自分のPCは色んなツールがいっぱいで動きが重い。)

OpenShiftを利用することにより、乱立する環境を整備し、かつ、容易に環境を構築することができれば、

無駄なコストは大幅に軽減されるのではないか、という期待を持てます。

したがって、まずはOpenShiftを触ってみて、基本的な機能でどこまで改善できるのかを探ってみました。

OpenShiftの利便性

OpenShiftというか、まずはコンテナの魅力として、HW、OSとの依存関係が切り離されることにより、

これらを意識しなくて済むことです。

アプリケーションとその実行環境だけを意識すればよいので、かなり楽になります。

さらに、OpenShiftでは、これらのContainerをPodという単位でラッピングし、各Node内に配置、

Masterで管理することができます。

また、下記図には記載されていませんが、OpenShift上にデプロイされるアプリケーションやPod、

その他のリソースはプロジェクトという論理的な単位で管理しています。

ProjectやPodの作成はWebコンソール画面から非常に簡単に実行することができます。

※次章をご参照ください。

ProjectやPodの作成手順

それでは、実際にProjectやPodを作成してみたいと思います。

◆Project/Podの作成

01.Openshift Web ConsoleにてCreate Projectボタンを押下して新プロジェクト作成画面へ
02. 必要項目を入力してプロジェクトを作成

03. テンプレートを元にコードをビルド&デプロイ

今回はOpenshift側で用意されたRubyのサンプルプロジェクトを自分のgithubにforkしたものを

使用します。カタログが表示されるので「Ruby」を選択。

04. アプリケーション設定画面が表示されるので、「Name」にアプリケーション名、「Git Repository URL」にソースのあるGithubのURLを入力します。

  ※これでGitとの連携ができちゃいます。

05. 上記画面で「advanced options」のリンクをクリックすると、Gitのブランチ、タグからの

ビルド&デプロイなど、さらに詳細な設定ができます。

  ※設定項目は多岐にわたるため、下記画面は中略しています。
06. 「Create」ボタンを押下するとPodのビルド&デプロイが開始されます。
07. 「Continue to overview」のリンクをクリックしてProjectの画面に移動します。

08. アプリケーションのビルドが完了したことを確認する。Podが立ち上がっていることが

確認できたら、「ROUTES External Traffic」に表示されたURLをクリックし、

アプリケーションにアクセスできるか確認します。

  ※以上でProjectの作成は完了です。Podも作成されます。(とても簡単です!)
◆Podの操作次にProject内にあるPodを操作してみたいと思います。

 

【Podのスケールアップ】

Podの追加・削除は、Pod数が表示されたリングの右側にあるスケールアップ、スケールダウン

の矢印をクリックするだけで可能です。

内部的なことは意識せずにPodが追加され、アクセスするURLも変化しません。

こうして複数のPodを作成すると、自動的に負荷分散もしてくれるようです。

【Gitのブランチ、タグからのビルド&デプロイ】

アプリケーション設定画面で「advanced options」のリンクをクリックし、「Git Reference」

の部分にタグを入力することでGitレポジトリ内のタグ・ブランチを指定してアプリケーション

をデプロイすることもできます。

一度作成したPodはOpenShiftの別Projectでビルドされたイメージを指定して

デプロイすることもできます。

これを応用すればテスト環境は開発環境と別Projectにすることができます。

別Projectで「Add to Project」→「Deploy Image」を選択します。

Projectの左メニューから「Resources」→「Membership」を選択するとMembershipの設定画面

となるので、プルを行うProjectのdefaultサービスアカウントに対し「system:image-puller」

の権限を付与します。

この後、改めて上記画面から設定を行い「Create」ボタンを押下するとビルド&デプロイが行われます。
ビルドデプロイが完了しましたが、Routeが作成されていないので「Create Route」をクリックして
Routeを作成します。
Createボタンを押下するとRouteが作成されます。
URLが生成されるのでクリックしてアプリケーションにアクセスすることを確認します。
※これでGitのブランチ、タグからのビルド&デプロイは完了です。(これも簡単です!)

 ここまでの感想

実際にProjectやPodを作成してみて、とにかく操作は簡単でした。

また、Container ではHW、OSを意識しなくていいということは冒頭でも記載しましたが、

OpenShiftを利用することにより、Podの増量によるスケールアウトがとても簡単に実行でき、

さらに、アプリケーションがURLで公開されることにより、IPアドレスも意識しなくて済みます。

※本ブログを掲載するにあたり、弊社ではOpenShiftの環境構築から実施していますが、

アプリケーション開発者であり、環境構築には疎いため、非常に苦労しましたが、

こういった形で環境を構築できることはすごく管理も楽であり、助かりますね。

※今回は試すことができていませんが、Containerが落ちた際に自動的に再起動してくれたり、

アクセス数が増えてきた場合に自動的にContainerを追加してくれたりもするようです。

開発プロジェクトでどう使うか

では、弊社のようなアプリケーション開発ベンダーが、社内の開発環境としてOpenShiftを利用する場合、

どういった利用方法がいいか、少し考察してみました。

まず、弊社でよくある開発パターンとして、以下のような例を挙げます。

1)   開発メンバーがローカルPC上に環境を構築し、開発・単体テストはローカルPCで実施する。

2)   結合テストは社内の仮想サーバ上に構築し、各メンバーで共有する。

3)   Gitによるソース管理は、本番用ブランチ、結合テスト用ブランチ、開発メンバー用ブランチ

に分かれている。

→開発メンバー用ブランチは各開発メンバー単位で用意し、開発・単体テストまで実施。

→結合テスト用ブランチは、開発メンバー用ブランチにてソースレビュー後にマージされ、

結合テスト環境にビルド、デプロイする。

→本番用ブランチは、結合テスト完了後に結合テスト用ブランチよりマージされ、

お客様環境にビルド、デプロイする。

これをOpenShiftを利用して開発する場合、以下のように改善が可能であると思われます。

1)   開発メンバーのローカルPCへの負荷が軽減される。また、OpenShiftへのアクセスもURLで可能であり、

Podの追加やスケールアウトも可能。

2)   Projectを分けることにより、管理者により各メンバーの権限を制御することができる。

3)   各Podは対応したブランチと紐づけることができるため、ブランチにPushすれば各Podへ自動的に

ビルド、デプロイされるため、手動での作業が不要となる。

開発プロジェクトで使う際の課題

とはいえ、課題もいくつか見えてきました。現状以下の課題(疑問点)があり解決できていません。

これについては、今後継続して調査、検証してみたいと思っています。

 

①DBサーバをOpenShift外に設置する必要がある?

上述の通り、OpenShiftではIPアドレスを意識しなくてよい仕様となっています。

その場合、アプリケーションサーバからDBサーバへの接続についてIPアドレスで接続することが

出来なくなります。

その場合、特にJavaで開発されている環境などでは、例えば、DBのIPアドレスを格納したOS環境変数

を元にDBサーバと接続するような処理をアプリケーション側で実装する必要があると思われます。

 

【後日談】

 Redhatに確認したところ、「OpenShiftでは同一プロジェクト内のPod間は、サービス名をホスト名

 として利用することができるため、それを使ってアクセスすることができる。」とのこと。

 したがって、このサービス名をJDBC URLのホスト名として設定するなどにより対応が可能となる。
 
 上述の弊社の課題(疑問点)としては、IPアドレスを意識しなくてよい(=IPアドレスが見えない)ため、
 例えばOpenShift内でDHCP的な動きをしているなどにより、名前解決ができないなどの問題があるかもしれない
 との懸念があって記載していましたが、上記のRedhatからの回答により解決できるものと思います。

 

②Dockerのimportができていない。

OpenShift外にあるDockerイメージを、OpenShift内に移行しようとした場合、OS、ミドルウェアなど

のインフラ部分はDocker側でイメージ化し、Gitなどとの連携情報についてはOpenShiftにてテンプレート

として取り込むなどの考慮が必要と思われる。

 そのため現状、Dockerイメージの取込みまでは正常に実行できるが、アプリケーションとして正常に接続が出来ない
 事象が発生している。

※Webコンソール画面からの操作で、容易に実行できないものだろうか・・・。

 

【後日談】

 OpenShiftのWebコンソール画面から移行することができるかと思っていましたが、

 Redhatに確認したところ、Gitリポジトリの情報をBuildConfigで定義し、s2iビルド

 にて実行するとのことでした。

 改めてこの方法で検証したいと思います。

Red Hat InsightsのPlanner機能

Red Hat Insightsに最近追加されたPlanner機能を紹介します。

レッドハットの森若です。

2年ほど前にこのblogの記事で Red Hat Insights をご紹介しましたが、最新のバージョンでは計画的な運用を助けるために活用できる「Planner」という機能が追加されています。この記事ではRed Hat InsightsのPlanner機能を中心として、最近のアップデートをご紹介します。

計画的な保守の重要性

ソフトウェアに限った話ではありませんが、システムの重大な障害を予防するためには計画的な保守が重要になります。いわゆる「重大なシステム障害」のほとんど(Red Hatサポート部門の知見ではおよそ85%)は既知の問題が重要なシステムで発生したもので、既に他のシステムで発生していてなんらかの緩和策・解決策が提供されているものです。

最新の知見をもとに、問題が発生するより前に各種の対策を行うことができれば、重大なシステム障害の発生を大きく減らすことができるでしょう。

Red Hat Insightsとは

Red Hat Insightsは既知の問題がシステムに存在しないかをチェックするための情報を定期的に収集し、対策に役立つレポートを出力するSaaS型のシステム分析サービスです。主に以下のような情報を確認して、問題の説明や対策をレポートします。

  • インストールされているパッケージ
  • 設定ファイル
  • ログ出力
  • 統計情報
  • ファームウェアバージョンなどの情報
  • インストールされているサードパーティ製品

 

執筆時点でおよそ400種類の問題をチェックしており、この数は継続的に増えています。Red Hat Insightsをシステムの健康診断のように利用することで、多くの重大な障害を予防できます。

Red Hat InsightsのPlanner機能

さて、最近追加された Planner機能とは何でしょう?

これは非常に簡単な機能で、検出された多数の問題に対する対策から任意に選んだものを「Plan」と呼ばれるグループにまとめる機能です。

Red Hat Insightsで提示される各種の対策を実施するときには、対象となるシステムの特性や問題の重大さなどにあわせて作業計画を立て、それに従って作業を進めていくことになります。Plannerを使ってそれぞれの対策をPlanにまとめることで、あるタイミングで行う作業を簡単にまとめられます。

対策がAnsibleに対応していれば、Planごとに対策用のAnsible Playbookを生成する機能を持っています。検出される問題の中にはAnsibleで対応できないものも含まれる点にご注意ください。たとえば「ネットワークのチェックサムエラーがxx%発生しているので物理的な問題をチェックしたほうがいい」というような問題の対策にはAnsible Playbookは含まれません。

Planに登録された問題と対策はRed Hat Insightsに保存され、次回以降のスキャンでその問題が継続しているか、対策済みかトラッキングされます。これにより作業の抜け漏れを防ぐこともできます。

参考文献

コンテナアプリケーションプラットフォーム「Red Hat OpenShift」を触ってみた Vol.2

【第2回】本記事では、コンテナアプリケーションプラットフォーム「Red Hat OpenShift」(以降、「OpenShift」と記載)を触ってみたエンジニアより、その概要と感想をご紹介したいと思います。

はじめに

本連載はサイオスグループのキーポート・ソリューションズの開発プログラマーが、コンテナアプリケーションプラットフォーム「Red Hat OpenShift」(以降、「OpenShift」と記載)を触ってみて、その概要と感想をご紹介します。(普段はアプリケーション開発に従事しているため、OS、ミドルウェアについては決して得意ではない筆者です。)
第2回目のテーマは「環境構築」、サーバ環境の準備からOpenShiftのインストールまでをゴールとし、極力自力で構築してみて課題や問題点を洗い出そうという主旨です。

環境構築時の作業リスト

事前の準備なしに1から環境構築を実施して発生した作業項目と作業時間を下記に記載します。
様々なエラーが発生し、調査も含めかなりの時間を要しましたが、本記事が皆様のトラブルシューティングの参考にしていたければと思います。下記にに発生事象などをご紹介したいと思います。
事前に準備ができていた場合、実際の作業量としては半日もかからない内容であると思います。
  ※「今回の作業時間」・・・手探りながらもなんとか実施した環境構築にかかった実績時間。調査時間が大半・・・。
  ※「今後の想定時間」・・・今回の環境構築により作成した手順書を元に、次回以降できるであろう想定の構築時間。

事前準備

開発プログラマーの立場からすると、ある意味OpenShiftの勉強からのスタートでした。Dev/Opsという言葉もあるため、今後はこのような仕組みも理解しなければならないと痛感します。
下記に環境構築にあたり参照したサイトをご紹介しておきます。
  • OpenShift Container Platform 3.6 Installation and Configuration

https://access.redhat.com/documentation/en-us/openshift_container_platform/3.6/pdf/installation_and_configuration/OpenShift_Container_Platform-3.6-Installation_and_Configuration-en-US.pdf

  • Install OpenShift Container Platform

https://docs.openshift.com/container-platform/latest/getting_started/install_openshift.html

次に、OpenShiftの推奨環境です。

要件

  • Red Hat Enterprise Linux 7.3 / 7.4
  • マスター:2vCPU、16GBメモリ
  • ノード:1vCPU、8GBメモリ
※All in One 構成も可能
上記の推奨環境を用意しようとしたのですが、弊社の諸事情によりMaster環境についてはメモリ8GBの環境しか用意できませんでした。

(このせいで後々ハマることには、この時点では気づきませんでした)
その後、RHEL 7.4 OSのインストールは難なく完了し、RHEL・OpenShiftのサブスクリプションも登録。
ちなみに、サブスクリプションは必ず登録しましょう!登録は以下のコマンドで簡単にできます。
#subscription-manager register
また、コマンドに慣れていない方はRHELのGUIからサブスクリプションメニューも用意されていますので、ご活用を。

OpenShiftインストールの前に

OpenShiftをインストール前にいくつかの設定が必要となります。
・DNSサーバの設定
  Master環境とNode環境をDNSサーバに登録する必要があります。
  
  MasterとNodeは互いにアクセスできるよう設定しておくことがポイントです。
  ちなみに、今回弊社では、外部からのOpenShift環境へのアクセスはさせたくなかったため、
      OpenShift環境(Master環境)内にDNSサーバを立てることにしました。
が、このせいで後々ハマッてしまうことに、現時点では気づきもしないのであった・・・。(その2)
・SSHの設定
  1. Node側のサーバでssh-keyを作成する。
#ssh-keygen
  2. 下記のコマンドを実行する
#ssh-copy-id -i ~/.ssh/id_rsa.pub XXX.XXX.XXX.XXX

・その他

  hosts設定、iptables設定等も実施。

 OpenShiftインストール

さあ、やっとOpenShiftのインストールです。
(事前確認から始めたため、ここまで来るのに数日かかりました・・・。自力で0から始めるのは大変ですね・・・。)
OpenShiftでは、いくつかのパッケージをインストールする必要があります。
ここでは詳細までは書ききれませんので、各パッケージのインストールコマンドのみ記載します。
なお、今回の環境構築では、アドバンスドインストールではなく、クイックインストールで実施しています。
※今回弊社では、詳細な手順書も作成していますが、それはまた別の機会に・・・。

1.パッケージインストール

ベースパッケージのインストール
→Master環境、Node環境それぞれで実行します。
yum install wget git net-tools bind-utils iptables-services bridge-utils bash-completion kexec-tools sos psacct
atomicパッケージのインストール
→Master環境、Node環境それぞれで実行します。
yum install atomic-openshift-utils
yum install atomic-openshift-excluder atomic-openshift-docker-excluder -y
システムパッケージのアップデート
→Master環境、Node環境それぞれで実行します。
yum update

2.Docker インストールと設定

dockerをインストール
→Master環境、Node環境それぞれで実行します。
yum install docker-1.12.6 -y
docker-storage設定
→Master環境、Node環境どちらかで実行すればOkです。
vim /etc/sysconfig/docker-storage-setup
docker-storage-setup

3.OpenShiftインストールと設定

OpenShift Container Platformをインストール
→Master環境、Node環境それぞれに対しインストールが必要ですが、片方のサーバにてまとめてインストールすることができます。
atomic-openshift-installer install
※インストール中の確認ポイント
→IPアドレスの入力を要求されます。このとき、Master環境のインストールか、Node環境のインストールか
 を質問されますので、まずはMaster環境をインストールします。
Enter hostname or IP address: 10.10.20.36
Will this host be an OpenShift master? [y/N]: y
→Master環境のインストールが完了すると、以下のサマリーが表示されます。
*** Installation Summary ***
Hosts:
– 10.10.20.36
  – OpenShift master
  – OpenShift node
  – Etcd
Total OpenShift masters: 1
Total OpenShift nodes: 1
NOTE: Add a total of 3 or more masters to perform an HA installation.
→続けて、ホストを追加するかどうかを質問されますので、次はNode環境をインストールします。
Do you want to add additional hosts? [y/N]: y
Enter hostname or IP address: 10.10.20.37
Will this host be an OpenShift master? [y/N]: n
→Node環境のインストールが完了すると、以下のサマリーが表示されます。
*** Installation Summary ***
Hosts:
– 10.10.20.36
  – OpenShift master
  – OpenShift node (Unscheduled)
  – Etcd
– 10.10.20.37
  – OpenShift node (Dedicated)
Total OpenShift masters: 1
Total OpenShift nodes: 2
NOTE: Add a total of 3 or more masters to perform an HA installation.
※「Hosts:」欄にNode側の環境も追加されています。
 また、「Total OpenShift nodes:」が「2」に増えていますね。
 なお、「Total OpenShift nodes:」が「2」になっている点についてですが、Master環境をインストールすると
 「1」となっているので、その際にNodeもインストールはされていますが、これはどうやらMaster環境が
 デフォルトでインストールするNodeであり、実際にユーザーが使用するNodeとは違うもののようです。

     ・・・こんなエラーが出ました!!

     
      推奨値である16GBに対し、5.8GBしかメモリがないよ!ということのようです。

推奨環境を用意できなかったツケが早速出てしまいました。

      調査したところ、インストール時にリソースの制限チェックが実行されており、これに引っかかってしまったことが判明。

下記の設定ファイルに対し、制限チェックをしない設定を追加し、なんとかクリアしました。

      ファイル名:「/root/.config/openshift/hosts」
      設定内容:
openshift_disable_check=disk_availability,memory_availability,docker_storage, docker_image_availability

4.疎通確認

      発生したエラーの調査も含め、3日間も費やしてしまいましたが、なんとかインストールが完了し、いざ疎通確認を開始。
      しかし、エラーは続けざまに発生するものです・・・。
NODEが”Ready”状態にならない!!
 
# oc get nodes
NAME                            STATUS                     AGE       VERSION
master.openshift.fiosys.co.jp   NotReady   16h       v1.6.1+5115d708d7
→調査したところ、OpenShiftでは全てのMaster、及びNodeでdnsmasqを使用するよう自動的に設定されますが、
 本事象では、こちらで立てたDNSサーバがポート53を使用しており、dnsmasqもポート53を使用するため、
 ポートが競合したために発生したものでした。

~参考~

※2 :
    
   ということで、気持ちとサーバをリフレッシュしようと、サーバを再起動して再度疎通確認を実施。
 すると、今度はNODE以前にOpenShift自体(Masterサービス)が起動しなくなってしまいました・・・。
 
  ※ちなみに正常に起動した場合は、下記のように表示されます。
 
再度調査を実施したところ、Master上で各NodeのPodやネットワーク情報を保持するetcdサーバがなぜか起動されていませんでした。
※おそらく自動起動するよう設定が必要と思われるが、今回はそこまでは調査できておりません。

手動でetcdサーバを起動することで、なんとかMasterサービスを起動することができました!

ということで、ついに環境構築が完了!
 
→「oc get nodes」コマンドでMaster、NodeともにReady状態になっていることを確認。
# oc get nodes
NAME                            STATUS                     AGE       VERSION
master.openshift.fiosys.co.jp   Ready,SchedulingDisabled   16h       v1.6.1+5115d708d7
node.openshift.fiosys.co.jp     Ready                      31m       v1.6.1+5115d708d7
 
→「oc get pods」コマンドでPodが稼働中であることを確認。


# oc get pods
NAME                       READY     STATUS    RESTARTS   AGE
docker-registry-1-3gnzp    1/1       Running   0          3m
registry-console-1-mm6dl   1/1       Running   0          4m
→ログイン画面を表示することが出来ました。
→ログインもできました!

→無事デプロイもできました!

注意すべきポイント(ハマッたことなど)

今回は普段よりアプリケーション開発に従事しており、ミドルウェアや基盤の構築はあまり経験がないメンバーにて
OpenShiftの環境構築を実施してみたのですが、かなり大変でした。
発生した事象は前述の通りですが、それ以外の細かい点も含め下記に記載しておきます。
  ●メモリ不足(制限チェックエラー)
   →推奨環境はきちんと守りましょう!
  ●Node状態が「Not Ready」になる事象(DNSサーバとポートが競合した事象)
   →用途が異なるものはサーバを分けましょう!
  ●サーバ再起動時にMasterサービスがactiveにならない
   →必要なプロセスはさらに勉強して把握しておきましょう!
  ●プロキシ設定に漏れがあった
   →Linuxをもっと勉強しましょう!

感想(大変だったことや今後の課題など)

今回環境構築を通してOpenShiftを触ってみて、感じたことを記載します。
  1.色んな参考サイトを見ながら構築作業を実施したが、そのまま利用できるものが見つからなかったため、
            やはり自分たちで手順書を作成する必要があると感じた。
  2.今回はクイックインストールで環境構築を実施したが、上述のエラーが発生した際に、
           その原因が分からず調査に苦労した。(実際にはRed Hatのサポートケースへの問合せも実施して対応)
    Red Hatの推奨はアドバンスドインストールとのことなので、今後改めて勉強し、理解する必要があると感じた。
  3.Red Hatのサポートケースで問合せたところ、迅速に回答が得られ、効果的であると感じた。
    また、コミュニティサイトを利用して質問を投げてみたが、こちらも比較的早めに回答が得られ、
            改めてOSSの強み(温かさ?)を感じることができた。

コンテナアプリケーションプラットフォーム「Red Hat OpenShift」を触ってみた Vol.1

第1回】本記事では、コンテナアプリケーションプラットフォーム「Red Hat OpenShift」(以降、「OpenShift」と記載)を触ってみて、その感想をご紹介したいと思います。

アプリケーション開発において、コンテナ技術の重要性が高まっているようです。金融IT分野のアプリケーション開発を生業としているサイオスグループの株式会社キーポート・ソリューションズ(以降:弊社)では今回、流行りに乗り遅れまいとレッドハット社が提供するコンテナベースのアプリケーションプラットフォーム「OpenShift」を触ってみることにしました。

実際、触るのは「これから」なのですが、今後数回にわたり以下のような観点で「OpenShift」を触ってみて、開発者視点でのメリットやデメリット、疑問点とその解決策、良い使い方がないか、などを探ってみたいと思います。

まずは、第1回目となる本記事では、「OpenShift」を触ってみることになった背景、目的、今回やってみたい内容などをご紹介したいと思います。

 

背景

以前、ポケモンGoが話題になったときにサーバ側処理が気になって調べたことがあります。Googleクラウド、Googleコンテナエンジン、Kubernetes、Dockerといったあまり馴染みのなかったワードが・・・。それまで、コンテナに対して、“便利なことができるんだろうなぁ“程度に思っていた私にとって、コンテナの有効性を初めて身近に感じた一件となりました。

さて、現在のIT業界において、コンテナの存在は急激に注目され始めています。そんな中、「OpenShift」はDocker、Kubernetesの機能に加えて、DevOpsに便利な機能を有すると謳われています。

OpenShiftによって、現課題は解消できる?開発の生産性は上がるの?運用は容易になるの?といった素朴な疑問を解消するためにもまずは触ってみよう!ということになりました。

 

  • アプリケーションを開発するにあたって現在の課題 (同じような課題をお持ちのベンダーさんは多いはず・・・)
    • 保守、開発しているシステムが多数あるが、システムごとに開発環境を用意しており、OS、M/W、フレームワーク、開発言語などさまざまで、環境が乱立している。
    • システムごとに環境や手順や異なるため、ナレッジを共有できず属人化している。(サーバ環境だけでなく、ローカル端末の開発環境も様々で、自分のPCは色んなツールがいっぱいで動きが重い。)
  • 素朴な疑問
    • 乱立している開発環境や手順など、本当に効率化できる?
    • 開発における生産性、スピードは本当に上がる?
    • DevOpsっていうけど、運用側のメリットって一体何?
    • コンテナによる環境の標準化の方法って?
    • また、標準化するために必要な下準備の内容とは?

などなど・・・。

そして、ひょっとするとこんな夢も叶えられるのでは?と次第に思うように・・。

  • このような課題や疑問を解決することは開発効率を上げることだけではなく、疲弊しがちな開発者のストレスも軽減し、ワークライフバランスまで改善したりするのかも・・・
  • 流行りのコンテナ技術を活用することによってDevOpsを実現するソリューションを提供することができるようになり、本分野における先駆けのSIerになれるかも・・・
  • そして、技術者個人としてもスキルアップできるかも・・・

目的

「OpenShift」を導入したとしても、使いこなせなければ効果は出ないはず。
というわけで、下記のような目的で「OpenShift」を触ってみることにします。

  • 目的
  1. メリット、デメリットを明確にする。
  2. 弊社のような開発ベンダーが利用するための情報を整理する。
  3. お客様環境に適用するための情報を整理する。
 

確認する内容

今後「OpenShift」を使って何をするか、を考えてみました。

 

基本的には、開発者視点で触ってみたいので、下記3点を試していきたいと思います。

① 環境を作る。
② OpenShiftをアプリケーション開発で利用する。
③ OpenShiftをアプリケーション運用で利用する。

■確認する内容

⇒「① 環境を作る」

      • 大変な部分はどこ?・・・みんなが詰まる部分を洗い出したい。
      • 必要な作業項目は?・・・今後、他の人が構築し易いようにTODOリストを作りたい。
      • 注意点すべき点はどこ?・・・パフォーマンス、リソース、設定などサイジングを考える上での元ネタを集める。

⇒「② OpenShiftをアプリケーション開発で利用する。」
「OpenShift」を触ってみる過程において、一番やってみたいことが盛りだくさんなのは、やはりアプリケーション開発です。
今回は弊社で持っている既存システムを試験的に移行し、軽微なPG改修を実施してみながら、以下の観点で確認したいと思います。

      • ビルド、デプロイの作業負荷は軽減できる?
      • システムの移行はスムーズにできる?
      • 複数システムの開発は容易にできるか?
      • 複数の開発メンバーによるビルド、デプロイ時の制御はできるか?
      • オーケストレーション機能ってどんなもの?
      • gitやJenkinsとの連携がスムーズにできるか?
      • ローカル端末の開発環境構築時の作業負荷は軽減できるか?

⇒「③ OpenShiftをアプリケーション運用で利用する。」
開発ベンダーとして「OpenShift」を利用する場合、その運用面においても気になる点がいくつもあります。
運用面においても前述の「②アプリケーションを開発する」にて移行、改修したシステムを用いて、以下の観点で確認したいと思います。

      • 開発環境用のコンテナを、そのまま本番環境にデプロイできるか?
      • パラメータを利用して簡単にコンテナ環境を構築することができるか?
      • 複数の開発メンバーによるビルド、デプロイ時の効率的なコンテナ管理方法は?
      • OS、M/W等のアップデートを自動化できるか?(もし試せれば。。)

ホネまでしゃぶろう、Red Hatサポート

Red Hatのサポート窓口では幅広いサービスを提供しています。今回はサポート窓口で提供しているサービスのうち、あまり知られていなさそうなものをピックアップして紹介します。

レッドハットの森若です。

今回はRed Hatのサポート窓口が提供するサービスのうち、あまり知られていなさそうなものをとりあげて紹介していきます。

システムのライフサイクルとサポート

システムのライフサイクルと、それぞれのフェーズにマッチするサポートのサービスをまとめたのが以下の図です。

 

レッドハット製品のサブスクリプションにはインシデント件数無制限の問いあわせ対応が含まれています。ここで何を問いあわせることが可能なのか、あまり意識していない方も多いかなと思います。

「Red Hatのプログラムに問題か問題らしい何かがあって、その対応が必要なときにバグレポートとか質問できるだけでしょ?」と思われているかもしれません。しかし問題が発生した時以外にもサポート窓口を活用することができます。

 

やりたいことができるか?の質問

新しいシステムを設計する際に、はじめて使うソフトウェアなどについて「自分がやりたいことが製品の範囲でできるのか、できるとするとどうやったらできるのか?」ということが気になります。このような時にもサポートへ問いあわせることができます。

たとえば以下のような質問に対応できます

  • 「Apache httpdでwebサーバを構築して、あるタイミングで現在どれだけ接続されているのかを測定したい。そういうことってできますか?どうしたらいいでしょうか?」
  • 「RHEL7.4のsambaでは xx という機能が有効になっていますか、それとも無効ですか?無効だとしたら同じようなことを実現する他の方法はありますか?」

 

アーキテクチャレビュー

いくつかの構築が難しい製品について「アーキテクチャレビュー」と呼ばれるプロセスが定義されています。サポート窓口でアーキテクチャレビューを申し込むことで、お客様が構築しようとしている、または構築したアーキテクチャのレビューをおこないます。

アーキテクチャレビューは以下を目的としています:

  • 適切に動作しないことがわかっている構成や設定についての指摘と排除
  • パフォーマンス上の問題につながる、注意するべき点の指摘
  • お客様の構成のうち、サポートされる範囲とサポートできない範囲を明確にする

アーキテクチャレビューにSLAは適用されません。「x月x日までに完了します」というようなお約束ができない点にご注意ください。

以下に各製品のアーキテクチャレビューについてナレッジベースエントリのリンクを記載します。必要な情報や制限などが記載されています。

 

プロアクティブチケット

ユーザへの影響を少なくするため、土日や深夜にアップデートなどの作業を行うことがあります。対応するPremiumサブスクリプションを購入している場合、休日や夜間であっても(重要度により)サポート窓口で問い合わせを受けつけることができます。しかしいざ問題が発生してからケースを作成し、システムの構成、作業内容、各システムのsosreport取得と登録、障害内容などを記載するとどうしても時間がかかってしまいます。

プロアクティブチケットはこのような場合に便利な仕組みで、Premiumサブスクリプションを所有していてケースのやりとりが英語で可能な場合、作業前にサポートケースを開いておくことができます。あらかじめ情報を共有し、担当サポートエンジニアが対応の準備をしておくことで実際に問題がおきた場合の初動を早くすることができる仕組みです。

プロアクティブチケットは通常のWebでの問いあわせと同じ窓口で、以下のように登録します。

  • 4営業日以上前にケースを作成
  • タイトルの先頭にProactiveとつけてケースを作成(重大度は3)
    • 例:  [PROACTIVE] – RHEL 7 kernel update
  • システムの現状および、予定されている作業についてできるだけ詳細を記載
    • 日程・イベント予定
    • 現状システムのsosreport
    • お客様の連絡先

プロアクティブチケットについては以下のナレッジをご確認ください https://access.redhat.com/node/286633

 

まとめ

今回はRed Hatのサポート窓口で提供されている、あまり知られていないサービス3種類をご紹介しました。

「Red Hatの製品はがっつり使っていて、サポートにもよく質問するよ」という方でも知らなかったものがあるかと思います。ご活用ください。

パフォーマンスチューニングを自動化するtuned

Red Hat Enterprise Linuxの6.0から、パフォーマンスチューニングに必要な設定をまとめておこなう tuned が同梱されています。今回はこのtunedをご紹介します。

レッドハットの森若です。

Red Hat Enterprise Linux のパフォーマンスチューニングを行いたい場合「どんな場合でも利用できるある1つの設定」というものはありません。たとえば以下のようなケースが考えられ、これらはそれぞれ異なる設定をおこなうことになります。

  • 計算スループットが重要で、イベントに対するレイテンシはあまり重要ではない場合
  • 省電力が重要なノートPCでのデスクトップ用途の場合
  • ネットワークのレイテンシを重視する場合

今回はこれらのパフォーマンスチューニング設定を簡易に行うための仕組みである tuned を紹介します。

tuned

tunedはRHEL 6.0から導入されたデーモンで、IOエレベータの設定、メモリ管理の設定、CPUスケジューラの設定、CPUの省電力設定、キャッシュのパラメータなどの各種設定をまとめたものを「プロファイル」として定義し、まとめて設定します。さらに仕組みを提供するだけでなく、典型的ないくつかのプロファイルを同梱しています。

このtunedを活用することで、典型的なケースについては非常に簡単にパフォーマンスチューニングを行うことができます。

tunedのプロファイル

早速tunedに添付されるプロファイルを見てみましょう。RHEL Server 7.4 で以下のようにコマンド 「tuned-adm list」により利用可能なプロファイルと現在設定されているプロファイルが表示されます。

# tuned-adm  list
Available profiles:
- balanced                    - General non-specialized tuned profile
- desktop                     - Optimize for the desktop use-case
- latency-performance         - Optimize for deterministic performance at the cost of increased power consumption
- network-latency             - Optimize for deterministic performance at the cost of increased power consumption, focused on low latency network performance
- network-throughput          - Optimize for streaming network throughput, generally only necessary on older CPUs or 40G+ networks
- powersave                   - Optimize for low power consumption
- throughput-performance      - Broadly applicable tuning that provides excellent performance across a variety of common server workloads
- virtual-guest               - Optimize for running inside a virtual guest
- virtual-host                - Optimize for running KVM guests
Current active profile: virtual-guest

それぞれのプロファイルについては man 7 tuned-profiles に概要が記載されていますが、 /usr/lib/tuned/プロファイル名/tuned.conf に設定が含まれていますので詳細はこれらのファイルを参照するのが手早いです。

表示ではわかりませんが balanced, latency-performance, throughput-performance, powersave の4種類が基本的な(方針の違う)プロファイルとして定義されており、その他のプロファイルはこれらを継承して少し変更する形で実装されています。

プロファイルの指定

tunedのプロファイル指定は、 「tuned-adm profile プロファイル名」で行います。指定すると即座に反映され、その後は再起動してもtuned起動時にプロファイルが適用されます。何もしていなければデフォルトでtunedは有効で起動されます。

現在有効なプロファイルを確認するには、 「tuned-adm active」とすると表示されます。同じものが「tuned-adm list」の最終行にも出力されます。

# tuned-adm profile latency-performance
# tuned-adm active
Current active profile: latency-performance

カスタムプロファイル作成時のヒント

独自にプロファイルを作成する場合は  /etc/tuned/プロファイル名/tuned.conf に必要な設定を記載することになります。include文にて既存のプロファイルをベースとすることもできます。

組織内で標準的に利用するtunedプロファイルを必要なパターンにあわせて定義しておけば、ファイルを数個設置してtuned-admで指定するだけで作業が完了しますので、初期設定作業が大幅に簡素化できます。

tuned.conf内で扱える設定は多岐に渡り、sysctlの指定、sysfsへの指定、ethtoolの指定、各種周辺装置の省電力設定、linux kernelの起動オプション(反映には再起動が必要)などがあります。さらにプロファイル適用時と適用終了時に実行するスクリプトも指定できますので、多くの場合はtunedのプロファイル内にパフォーマンスチューニング設定を集約することができます。

関連ドキュメント

継続的な学習を実現する Red Hat Learning Subscription

エンジニアの技術力の向上には継続的な学習が必要です。Red Hat公式トレーニングの全コースをいつでも学習できるRed Hat Learning Subscriptionをご紹介します。

レッドハットの森若です。

次々と新しい技術や製品が登場する昨今、エンジニアは継続的な学習が必須となっています。みなさまはどのようにして新しい技術を獲得しているでしょうか? 今回はレッドハットが提供する Red Hat Learning Subscription をご紹介します。

トレーニングの必要性

社内の技術力を高めて事業へ貢献するためには、継続的な学習が必要です。たとえばコンテナによるアプリケーションの配備のような新しい技術をキャッチアップすることでインフラの選択肢を増やす、現在利用している技術へより深い理解を得ることで障害時の障害解析をスムーズにする、AnsibleのPlaybookを書けるようになって日常業務の自動化を行うなど、多くのシーンで様々な技術を習得する必要があります。

トレーニングをするときの課題

トレーニングに必要なものは何でしょうか?

学習のための環境

たとえばAnsibleの学習をする際、Ansibleが動作するマシン、管理されるマシン1台(できれば2台)の合計2台あるとできそうです。OpenStackではどうでしょう。コントローラに3台、Directorに1台、コンピュートに2台、さらに共有ストレージ役のNFSサーバで計7台くらいでしょうか……?

これから学習しようという場合、必要台数や条件がよくわからないこともありますし、利用できるリソースが限られていることも多いでしょう。またたとえば1ヶ月学習のために時間がとれても、最初の2週間ほどが基本的な環境構築に費されるということもよくあります。

エンジニアの時間

レッドハットの公式トレーニングでは、コースによっては教室で4日間のハンズオントレーニングを行っています。連続して学習に集中できる環境は非常に学習効果が高いですが、「4日間連続してスケジュールを押さえる」こと自体が難しい場合も多いです。

信頼できる資料

多くのソフトウェアについて、簡単な紹介や「やってみた」というblog記事などはインターネットにあふれていますが、わずかな例外を除けば、ある技術を身につけるために使える信頼できる資料というものは滅多にみつからないものです。たとえば「AnsibleのPlaybookを書けるようになりたい」というときに公式マニュアル以上の、説明・例題・演習を含めたテキストが見つかるでしょうか?

Red Hat Learning Subscription

Red Hat Learning Subscription とは、オンラインで利用できるサブスクリプション制のトレーニングです。1年間有効なサブスクリプションとして販売され、期間中はレッドハット公式トレーニングの全コース(現在44コース)を好きなタイミングで受講することができます。
日本の教室トレーニングで実施されているもののほとんど(12コース)はテキストが和訳されています。また日本で実施されていないコース(32コース)も英語で受講できます。

さきほど挙げた3つの点について見てみましょう

学習のための環境

各コースにはコース内容にあわせたラボ環境があらかじめ用意されており、オンデマンドで5分程度で利用できるようになります。このラボ環境は年間400時間利用可能なので、単純計算で平均毎週8時間ずつ演習ができます。

 

エンジニアの時間

24時間365日いつでもアクセスできますので、隙間時間での受講が可能です。スマートホンなどからも接続できるため、通勤電車でテキストを読んだり、テキストをタブレットで表示しながらラボをPCで実施するなども可能です。

信頼できる資料

15年以上の実績があり高い評価を受けているレッドハットの教材がそのまま利用できます。トレーニングの資料はレッドハットが継続的にメンテナンスしています。テキストやラボに技術的な問題がある場合、英語に限定されますがサポート窓口を利用できます。

さらにRed Hat Learning Subscriptionでは、コースを横断した全文検索が利用できます。コマンド例のコピー&ペーストなども簡単にできますので紙の資料より便利かもしれません。

まとめ

継続的な学習のために必要な各種の特長をもつ Red Hat Learning Subscription をご紹介しました。もしご興味があれば sales-jp@redhat.com までご相談ください!

関連資料

Red Hat Enterprise Linux 7.4 public betaがでました

Red Hat Enterprise Linux 7.4のPublic betaが出荷されました。Public betaを試すときに気になるポイントをまとめました。

レッドハットの森若です。

2017年5月24日にRed Hat Enterprise Linux 7.4のPublic betaが出荷されました。Public betaを試すときに必要な情報をまとめました。

Public Betaとは

Red Hat Enterprise Linux 7.3は2016年11月3日に出荷されました。そのため現時点でおよそ半年経過しています。Public betaは機能追加などがひととおり終わり、ある程度社内でのテストを行ったものが公開されています。Public beta出荷から通常さらに2〜3ヶ月ほどテストおよび修正をおこなったのち製品版が出荷されます。

Public betaは何かRed Hat製品を持っている人であれば誰でも入手でき、追加のサブスクリプション費用は不要です。試していて何か問題をみつけた場合、サポート窓口までお報せください。最終製品の改善に役立ちます。

注意点としては、Beta版から製品版へのアップデートはできませんので、将来出荷されるRHEL 7.4のシステムを構築するなどの目的には利用できません。

Public Betaの入手

ではPublic betaを入手してみましょう。

カスタマーポータルのダウンロードページへ行きます。評価版やDeveloper Programでもよいですが、何かしらのサブスクリプションを持っているアカウントが必要です。

https://access.redhat.com/downloads/content/69/ver=/rhel—7/7.4%20Beta/x86_64/product-software

アップデート内容は?

さて、RHEL7.4 ではどのような変更がやってくるのでしょうか? Public betaにはリリースノートがありますので、そちらを確認することで主要な変更点を確認できます。このリリースノートはまだ抜け洩れがある状態で公開され、製品リリース直前まで随時更新されます。ここに記載されているものが変更点の全てとは言えない点にご注意ください。

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html-single/7.4_Release_Notes/index.html

RHEL7.4 public betaのリリースノートを読んで私が個人的に気になった新機能やバグフィックスについて、以下でまとめています: https://togetter.com/li/1113512

問題があったら?

Public betaはサポートの対象ではありませんが、バグレポート、障害レポート等は受け付けています。

パフォーマンスの劣化、今まで動作していたソフトウェアが動作しないなどの非互換など、怪しい動作があればぜひサポート窓口までお報せください。