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
- vagrant-provision.sh
#!/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に関連していろいろリリースされています。随時更新します。
- WildFly Swarm 1.0.0.Final
- JBoss EAP 7.0.0.GA
- JBoss Core Services Collections
- Red Hat SSO 7.0
- JBoss Developer Studio 10.0.0.GA
- JBoss Tools 4.4.0.Final
- Vert.x 3.3.0
- OpenShift Enterprise 3.2.1.1
- Red Hat Container Development Kit 2.1.0
- OpenJDK 8 for Windows
- .NET Core 1.0 support on RHEL and OpenShift
- OpenShift Container Platform (formerly known as OpenShift Enterprise)
- Red Hat CloudForms 4.1
- Ansible Container
JJUGナイトセミナー Javaクラウドプラットフォーム大特集でOpenShiftの話をしてきました
JJUGナイトセミナー Javaクラウドプラットフォーム大特集でOpenShiftのお話をしてきました。
#jjug 満員御礼です! pic.twitter.com/2LE5GolA3M
— Shin Tanimoto (@cero_t) March 22, 2016
スライドはここです。ハイライトをこちらにも書いておきます。
- 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は使ってませんが、そのうち使う例も書くかもしれません。
- Nexus開く
- 右上のLogin、admin/admin123
- Repositoriesタブのadd、Proxy Repositoryでredhatという名前、URLは https://maven.repository.redhat.com/ga/
- Repositoriesタブのadd、Repository Groupでmainという名前、リポジトリにCentralとredhat追加
これで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.xml
のprojectConfig: 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にすることにしたのであった。
初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すれば普通に使えるということになる。