nekop's blog

OpenShift / JBoss / WildFly / Infinispanの中の人 http://twitter.com/nekop

Fedora 24でoc cluster upを利用してOpenShift Originをセットアップする

超簡単バージョン。数行のコマンドでOpenShift Originのセットアップがおしまいだ。バージョンはOrigin v1.3.0-alpha.2。

この例ではVagrantで手元のFedora 24のVMを利用しているけど、どのクラウド上でも、OSもCentOSでもAmazon LinuxでもDockerの新しいの入ってればたぶん動きます。

  • Vagrantfile
Vagrant.configure(2) do |config|
  config.vm.box = "fedora/24-cloud-base"
  config.vm.provider "libvirt" do |libvirt|
    libvirt.driver = "kvm"
    libvirt.memory = 2048
    libvirt.cpus = 4
  end
end
  • セットアップ
vagrant up
vagrant ssh
sudo dnf install docker -y
sudo sh -c "echo INSECURE_REGISTRY='--insecure-registry 172.30.0.0/16' >> /etc/sysconfig/docker"
sudo systemctl start docker
sudo systemctl enable docker
curl -LO https://github.com/openshift/origin/releases/download/v1.3.0-alpha.2/openshift-origin-client-tools-v1.3.0-alpha.2-983578e-linux-64bit.tar.gz
sudo tar xf openshift-origin-client-tools-v1.3.0-alpha.2-983578e-linux-64bit.tar.gz  --strip=1 -C /usr/bin openshift-origin-client-tools-v1.3.0-alpha.2-983578e-linux-64bit/oc
sudo curl -L https://raw.githubusercontent.com/openshift/origin/master/contrib/completions/bash/oc -o /etc/bash_completion.d/oc
. /etc/bash_completion.d/oc
sudo oc cluster up
  • oc cluster upのログ
$ sudo oc cluster up
-- Checking Docker client ... OK
-- Checking for existing OpenShift container ... OK
-- Checking for openshift/origin:latest image ... OK
-- Checking Docker daemon configuration ... OK
-- Checking for available ports ... OK
-- Checking type of volume mount ... 
   Using nsenter mounter for OpenShift volumes
-- Checking Docker version ... OK
-- Creating volume share ... OK
-- Finding server IP ... 
   Using 192.168.121.163 as the server IP
-- Starting OpenShift container ... 
   Creating initial OpenShift configuration
   Starting OpenShift using container 'origin'
   Waiting for API server to start listening
   OpenShift server started
-- Installing registry ... OK
-- Installing router ... OK
-- Importing image streams ... OK
-- Importing templates ... OK
-- Login to server ... OK
-- Creating initial project "myproject" ... OK
-- Server Information ... 
   OpenShift server started.
   The server is accessible via web console at:
       https://192.168.121.163:8443

   You are logged in as:
       User:     developer
       Password: developer

   To login as administrator:
       oc login -u system:admin

ついでにログイン面倒なのでデフォルトでsystem:adminでログイン状態にしておく。

mkdir ~/.kube/
sudo cat /var/lib/origin/openshift.local.config/master/admin.kubeconfig > ~/.kube/config

origin containerはhost networkの:53をLISTENして名前解決できるようにしているのですが、VMを利用せずに素でセットアップしたFedora 24 Workstationなどで上で同じことをした場合、Docker containerからのDNS queryをfirewallがはじいてしまうのでpodが動作しません。以下のコマンドで許可する必要があります。また、:53が既にふさがってる場合なども動作しません。dnsmasqやlibvirtdでdnsmasqが動作している場合などは止めておく必要があります。

sudo firewall-cmd --add-service=dns
sudo firewall-cmd --runtime-to-permanent

Fedora 24でOpenShift Originをセットアップする

Fedora 24にOpenShift Originが追加されたのでセットアップしてみる。以下の2ファイルを作ってvagrant upすればおしまい。インストールされるバージョンは1.2.0のようだ。

  • Vagrantfile
Vagrant.configure(2) do |config|
  config.vm.box = "fedora/24-cloud-base"
  config.vm.provision "shell", path: "vagrant-provision.sh"
  config.vm.network :private_network, ip: "192.168.232.101"
  config.vm.provider "libvirt" do |libvirt|
    libvirt.driver = "kvm"
    libvirt.memory = 2048
    libvirt.cpus = 4
  end
end
#!/bin/bash

IP_ADDR=192.168.232.101

sudo dnf install -y ansible pyOpenSSL python2-dnf git dbus-python libsemanage-python NetworkManager
sudo systemctl start NetworkManager
sudo systemctl enable NetworkManager
git clone https://github.com/openshift/openshift-ansible/
cat /dev/zero | ssh-keygen -q -N "" &> /dev/null # silent ssh-keygen
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
ssh $IP_ADDR -o StrictHostKeyChecking=no id # add it to known_hosts
ANSIBLE_HOSTS=$(cat <<EOM
[OSEv3:children]
masters
nodes

[OSEv3:vars]
ansible_ssh_user=vagrant
ansible_become=true
deployment_type=origin
openshift_master_identity_providers=[{'name': 'allow_all', 'login': 'true', 'challenge': 'true', 'kind': 'AllowAllPasswordIdentityProvider'}]
osm_default_subdomain=apps.$IP_ADDR.xip.io

[masters]
$IP_ADDR openshift_node_labels="{'region': 'infra'}" openshift_schedulable=true

[nodes]
$IP_ADDR openshift_node_labels="{'region': 'infra'}" openshift_schedulable=true
EOM
)
echo "$ANSIBLE_HOSTS" | sudo sh -c "cat > /etc/ansible/hosts"
ansible-playbook ./openshift-ansible/playbooks/byo/config.yml

Red Hat Summit 2016 / DevNation 2016 でのリリース

今週サンフランシスコで開催されているRed Hat Summit 2016 / DevNation 2016に関連していろいろリリースされています。随時更新します。

JJUGナイトセミナー Javaクラウドプラットフォーム大特集でOpenShiftの話をしてきました

JJUGナイトセミナー Javaクラウドプラットフォーム大特集OpenShiftのお話をしてきました。

スライドはここです。ハイライトをこちらにも書いておきます。

  • OpenShift Online (v2)は3アプリケーション無料でがんばってます
  • Dockerはサーバサイドソフトウェアの流通形態を変える超重要コンポーネント
  • Dockerをフルに活用するために、OpenShift v3はDockerを前提としてフルスクラッチで開発。他のDocker"も"使えます的なPaaSとはその点が顕著に異なり、Dockerがファーストクラスコンポーネントになっている
  • OpenShift = Docker/Kubernetes + みんなで簡単に使えるようにする機能群
    • 逆に言うと、Docker/Kubernetesだけではみんなで簡単に使えません
    • OpenShiftがUI、ユーザ管理、マルチテナント、ネットワーク、イメージビルド基盤を提供
  • OpenShiftにソースコード、Dockerイメージ、Dockerfileなどを放り込むとビルドしてデプロイして利用可能にしてくれる
  • PaaSが最も活用できるのは開発作業。しかし各開発者に自由に従量課金のパブリッククラウドPaaSを使わせるというのは多くの場合コスト管理上難しく、開発者側も従量課金コストが発生する場合は気軽に使えないプレッシャーを受ける。しかし、気軽に使ってもらえないとPaaSの恩恵はフルに受けられない。そのような背景があってPaaSはオンプレミスで活きる場合が多い
  • アプリケーション開発者はアプリケーション開発に専念して価値を創出すべき。開発者のマシンでVMあげたり、VMリソースは払い出すけどセットアップはやってね、とかDBのインストールとセットアップとかやらせる、というような状況は本来避けたいもの

PaaSは無くても生きていけないわけではないので見過ごされがちですが、あるとすごく便利です。社内にPaaSがあることによってアプリケーション開発者が社内で勝手に便利アプリケーションを作ってホストするようになったという副次的効果があったというお話も聞いていますし、使い込めば開発生産性のブースターとしても機能する強力なプラットフォームですので、ぜひお好きなPaaSを試してみてください。

OpenShift Enterprise 3.1.1にNexusをデプロイする

Mavenリポジトリミラーが内部にあったほうがビルドが高速になって便利なのでOpenShift Enterprise 3.1.1上につくります。

oc new-app sonatype/nexus
oc expose service nexus

簡単ですね。これでNexusに http://<nexus url>/ でアクセスできます。この例ではPersistenceVolumeは使ってませんが、そのうち使う例も書くかもしれません。

これでCentralとredhatをキャッシュしてくれるMirror Repositoryができました。

JBoss EAPのs2i builderでは以下のようにBuildConfigのenvで指定すれば、指定されたミラーが利用されるようになり、Nexusがjarをキャッシュしてくれるのでビルドが高速になります。

spec:
  strategy:
    sourceStrategy:
      env:
      - name: MAVEN_MIRROR_URL
        value: http://<nexus url>/content/groups/main/

OpenShiftのnodeSelector

OpenShiftのpodはnodeSelectorによって利用するノードが決まります。nodeSelectorにはざっくり2つのレベルがあり、projectのnodeSelectorとDeploymentConfigのnodeSelectorがあります。

上位のproject (namespace)レベルのnodeSelectorは、openshift.io/node-selectorアノテーションで指定されます。このプロジェクトのpodは全てこのregion=infraラベルの付与されたノード群にしかデプロイされません。

$ oc describe project default
Name:           default
Created:        18 hours ago
Labels:         <none>
Annotations:        openshift.io/node-selector=region=infra
            openshift.io/sa.initialized-roles=true
            openshift.io/sa.scc.mcs=s0:c1,c0
            openshift.io/sa.scc.supplemental-groups=1000000000/10000
            openshift.io/sa.scc.uid-range=1000000000/10000
Display Name:       <none>
Description:        <none>
Status:         Active
Node Selector:      region=infra
Quota:          <none>

アノテーションの付与にはoc annotate namespaceを利用します。projectはnamespaceのエイリアスでread-onlyなので、projectは更新できません。

oc annotate namespace default openshift.io/node-selector=region=infra

projectのnodeSelectorのデフォルトはmaster-config.xmlprojectConfig: defaultNodeSelectorに定義できます。プロジェクトにこのopenshift.io/node-selectorアノテーションが付与されていない場合は、defaultNodeSelectorが暗黙で適用されます。

/etc/origin/master/master-config.xml

projectConfig:
  defaultNodeSelector: region=primary

project (namespace)の書き換えはOpenShift管理者の権限が必要で、ユーザはprojectレベルのnodeSelectorを超えてpodをデプロイすることはできません。これを利用して、OpenShift管理者は特定のプロジェクトに専用のノードを割り当てたりすることができます。

ユーザはDeploymentConfigに追加でnodeSelectorを指定できます。例えば地域ごとにノード群にzone=tokyo1などのラベルを付与しておくことで、ユーザはnodeSelectorを指定してレイテンシの低いローカル地域のノード群にpodをデプロイ、というようなことが可能になります。

template:
  spec:
    nodeSelector:
      zone: tokyo1

Dell XPS 13 2015をFedora 23にした

奥さんのラップトップ、以前はそこそこ大きいのが良いということでInspiron 15 2010年モデルだったんだけど、少し前にHDDが壊れてしまいWindowsとはおさらば、SSD換装してFedora 21という構成にしていた。最近は子供も居るしちょこちょこ使うユースケースが増えて、やはりもう少しコンパクトでかわいいラップトップがいい、ということでMac超え狙って開発したという話のDell XPS 13 2015 (XPS 9350 Skylake model)を買っていた。なかなかかっこいいボディである。

プリインストールされているWindows 10で試しに運用してみたのだけど、やはりWindowsに慣れていないので仕事しづらいということと、日本語入力がなぜかデフォルトでカナ入力になるという現象が発生して設定いろいろ探して変えたけどなおらないという微妙な状態になってしまい、非技術系な奥さんですらFedoraのほうが使いやすいという話になってFedora 23にすることにしたのであった。

  • Win上でBIOSアップデート
  • 起動F2でBIOSに入ってUEFIブートをLegacyへ、Secure Boot無効化、RAIDをAHCIへ変更
  • USBブートしてFedora 23インストール

UEFIでこのへん手間どった。BIOSアップデートしていないとFedora 23のインストーラが起動時にカーソル出して固まる。

インストールしたFedora 23起動するとWiFiが認識されない。調べてみるとBroadcomのもので、対応するLinuxのドライバがない、もしくは不安定、という状況のWiFiチップのようだ。

sudo lspci -vnnの結果が以下。

3a:00.0 Network controller [0280]: Broadcom Corporation BCM4350 802.11ac Wireless Network Adapter [14e4:43a3] (rev 08)

ここでおもむろにNexus 6をUSB接続してテザリング、Nexus 6は自宅のWiFiにつないでるのでとりあえず結果的にWiFiに接続している状況にしていろいろ試行錯誤。

まずはsudo dnf update -yカーネルも最新にしてリブートしたけど状況変わらず。

いろいろ調べていくと標準のbroadcom向けドライバは未対応、rpmfusion-nonfreeのbroadcom-wlが対応しているかもしれないという情報を元にインストールしてみたけどダメ。

他に43a3はLinux 4.4カーネルのbrcmfmacというドライバで対応しているという情報があったので、試してみることに。Fedora 23の現時点でのstableのカーネルは4.3.5だが、Linux 4.4カーネルはtestingにある状況なのでそちらをインストールしてみる。

sudo dnf install kernel -y --enablerepo=updates-testing --bestでkernel-4.4.2-301が入るのでリブートしてみるとビンゴ、WiFiが使えるようになった。今のところ特に不安定ということもなく、普通に使えている。

調べている過程で、多くの人はこのXPS 13にLinuxをインストールするためにWiFiチップをIntelのものに換装という手をとっているみたいだったけど、XPS 13のアルミ削り出しボディ開けるのも結構シビアでツメ折れるリスクがあるという記述もあったので、やらなくて済んで良かった。

追記: 次の日dnf updateしたらstableからkernel-4.4.2-301が落ちてきたというオチ。今日以降の人はとりあえずネットワークをゲットしてdnf updateすれば普通に使えるということになる。