久しぶりにコンソールサーバ(NS-2250)を触って調べるの面倒だったのでメモ

f:id:komeiy:20150107164847j:plain

はじめに

タイトルの通りです。久しぶりに拠点のネットワークに関わることがあったのですが、マニュアルで調べるの面倒・・・って時間がもったいない思いしかなかったので、 どこかで誰かも同じ事思っているかもなので書いておきます。一応書いておきますが、特にマニュアルが不十分とかじゃないんですよね。野良情報が少ないんですよね。 デフォルトがどういう状態か把握できてないってだけなんですよね。20分30分費やし出すとイライラするってだけなんです。

マニュアル

マニュアルはこのあたり。本当は公式サイトで最新を落としておいた方がよい。 でもフォームに入れるの面倒ってなる。

https://www.seiko-sol.co.jp/wp-content/uploads/2016/02/NS-2250series_Command_Reference_03.pdf

https://www.seiko-sol.co.jp/wp-content/uploads/2016/02/NS-2250series_Users_Manual_01.pdf

基本設定

今回は以下のバージョンの記事です。

Main System : Ver 1.3

デフォルトは root のパスワードなしでコンソールを接続して作業する。 これも毎回調べるんですよね。

以下はほぼ全員入れるかなと。

<hostname># set hostname <hostname>
<hostname># set timezone Tokyo

<hostname># set ipaddr eth1 192.168.0.1/24
<hostname># create ip route default gateway 192.168.0.254

<hostname># set portd idle_timeout on 30
<hostname># set portd tty 1-48 timeout on

<hostname># set sshd auth basic
<hostname># enable sshd

ユーザ設定

パスワードも変更しておきます。例えば、root が空だと su できなかったり困るので。

<hostname># set user root password
<hostname># set user somebody password

お好みでポートアクセス可能なユーザを作っておくとよいと思います。

<hostname># create user <user> group portusr port 1-48 password

<hostname># show user
User-Name        Category(Uid)    Public-Key  Port-Access-List
 --------------------------------------------------------------
 root             root(0)
 setup            setup(198)
 verup            verup(199)
 log              log(200)
 somebody         normal(100)
 <user>           portusr(501)                 1-48
 portusr          portusr(500)                 1-48

SSH 設定

デフォルトはダイレクトモードです。ポート番号を 8101 とか 8301 でアクセスします。 以下のように物理ポートと TCP のポートがマッピングされています。

<hostname># show portd
auth status    : none
connect status : direct
base port number
         telnet rw :  8101  ro :  8201
         ssh    rw :  8301  ro :  8401
timeout status
  idle_timeout : on  (  30min)
  ro_timeout   : off
menu status    : auto
--------------------------------------------------------------------------
tty Label                             Listen Port              TimeOut
                                      telrw telro sshrw sshro  idle   ro
--------------------------------------------------------------------------
  1 switch1                             8101     -  8301     -    30    -
  2 switch2                            8102     -  8302     -    30    -
  3 switch3                            8103     -  8303     -    30    -
  4 switch4                            8104     -  8304     -    30    -

もう telnet でアクセスできるようになってますが、 最初は SSH でのアクセスはできない状態なのです。

その理由は、以下のコマンドで確認可能です

<hostname># show allowhost
Service         Address/Mask                            Access tty List
--------------------------------------------------------------------
portd/telrw     all                                     all
telnetd         all              

以下で ssh をできるようにしておきます。

<hostname># create allowhost all service sshd all
<hostname># show allowhost
Service         Address/Mask                            Access tty List
--------------------------------------------------------------------
portd/telrw     all                                     all
sshd            all                                     -
telnetd         all                                     -

ポートアクセスも SSH でできるようにしておきます。

<hostname># create allowhost all service portd sshrw all
<hostname># show allowhost
Service         Address/Mask                            Access tty List
--------------------------------------------------------------------
portd/sshrw     all                                     all
portd/telrw     all                                     all
sshd            all                                     -
telnetd         all                                     -

その他

sntp とか syslog を設定しておきましょう

<hostname># set sntp server 172.16.1.1
<hostname># enable sntp

<hostname># set syslog host 1 172.16.1.2 syslog_facility local7
<hostname># enable syslog

終わりに

write があるのでお忘れなく

徹底攻略Cisco CCNP Routing & Switching SWITCH教科書[300-115J]対応

徹底攻略Cisco CCNP Routing & Switching SWITCH教科書[300-115J]対応

ネットワーク超入門講座 第4版

ネットワーク超入門講座 第4版

GCP の Interconnect や CloudVPN に GCS のトラフィックを乗せる方法

GCP の Interconnect や CloudVPN に GCS のトラフィックを乗せる方法を調べた時にいい感じにまとまったページがなかったのでメモしておきます。

概要

まずなんでこれをやりたいかというと、まず初めに 転送コスト です。コストがかかる方向は制限されますが、結構ばかにならないです。 例えば Partner Interconnect であれば 1/2 から 1/3 程度のコストに抑えられます(※ 記事執筆時点の情報。ポート利用料など別課金あり)

あとはレイテンシやセキュリティなど理由は様々あると思います。

実現するにあたり、方法は何個かあるかと思います。

一番綺麗なのは 「*.googleapis.com が restricted.googleapis.com への CNAME として解決されるようにして、Interconnect や CloudVPN 上にトラフィックがいくようにルーティングをいじる」だと思います。実は試してはないのでうまくいくのかはわかってないです。

オンプレミス ホスト用のプライベート Google アクセスの構成  |  VPC  |  Google Cloud

2番目に、踏み台用意して GCS のトラフィックを強引に中を通す方法です。 イメージとしては以下の図のようになります。図中の②を通すイメージです。

f:id:komeiy:20190301212651p:plain

f:id:komeiy:20190301212656p:plain

割と簡単ですね。検証も楽なので試してみます。

踏み台利用パターン

flunetd の plugin など利用していると困るのですが、今回はターゲットを gsutil を利用している場合とします。 gsutil は proxy を利用することが可能なので割と簡単に実現可能です。もうこの時点でハイハイってなっている人多いので書く必要があるのかというツッコミもありそうですが。

以下を見るのがわかりやすいです。

Boto を使用する場合  |  Cloud Storage  |  Google Cloud

該当箇所は以下の通り

$ cat .boto | egrep "^proxy"
proxy = localhost
proxy_port = 3128

まずは proxy をセットした後に gsutil で疎通ができないことを確認。適当に snmpd_strace_output.txt という名前のテキストを置いておきました。

$ gsutil cp gs://<your bucket>/snmpd_strace_output.txt .
INFO:root:Retrying request, attempt #4...
INFO 0227 20:49:30.945226 retry_util.py] Retrying request, attempt #4...

プロキシサーバとして、今回は squid を立てます。構築が面倒でしたので、こちらを参考にさせて頂きコンテナで構築します。

$ docker run  -p 3128:3128 -ti docker.io/salrashid123/squidproxy /apps/squid/sbin/squid -NsY -f /apps/squid.conf.forward

プロキシサーバは以下のように確認可能です。

$ curl -v -x localhost:3128  https://www.yahoo.com/

はい、できるようになりました。

$ gsutil cp gs://<your bucket>/snmpd_strace_output.txt .
Copying gs://<your bucket>/snmpd_strace_output.txt...
/ [1 files][  1.6 KiB/  1.6 KiB]
Operation completed over 1 objects/1.6 KiB.

最終的には localhost ではなく別のインスタンスからプロキシ経由でアクセスするので GCP 側の firewwall 開ける必要あります。

proxy が EIP 持つ必要なかれば private Google Access にしちゃいましょう。簡単です。 普通にONにするだけ、EIP取ってもプロキシ経由で疎通できることを確認しておきます。

$  gsutil cp gs://<your bucket>/snmpd_strace_output.txt .
Copying gs://<your bucket>/snmpd_strace_output.txt...
/ [1 files][  1.6 KiB/  1.6 KiB]
Operation completed over 1 objects/1.6 KiB.

限定公開の Google アクセスの構成  |  VPC  |  Google Cloud

その他

課題となる点は冗長性かなと思います。 特定のサブネットのアドレスでプロキシと疎通取れれば良いので、Kubernetes なり別のレイヤーで担保するようにするのが良さそうです。


シェアして頂けると嬉しいです。
参考になったという方がいれば是非お願いしますm(_ _ )m
モチベーション維持の観点で非常に励みになります。

このエントリーをはてなブックマークに追加

Google Cloud Platform エンタープライズ設計ガイド

Google Cloud Platform エンタープライズ設計ガイド

クラウドエンジニア養成読本[クラウドを武器にするための知識&実例満載! ] (Software Design plusシリーズ)

クラウドエンジニア養成読本[クラウドを武器にするための知識&実例満載! ] (Software Design plusシリーズ)

KubernetesのNetworkPolicyとかNodeAffinityやinitContainersを備忘録的にメモ

f:id:komeiy:20150107164847j:plain

タイトルの通りですが、備忘録です。 色々と機能あるので知らないことがいっぱいです。記憶定着させる意味も込めて書いているのでそんなたいした内容はないです。

The NetworkPolicy Resource

ほぼ公式に書いてあるから不要かもですが、サンプルだとこんな感じ。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

この pod からあのへの通信だけ許可するみたいなときに使います。 以下のように記載して、 role: db というラベルがついた pod へは role: frontend というラベルがついた pod からしか通信できないようにするものです。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend

使い所ありそう。

Node Affinity

これもほぼ公式に書いてあるのですが、初見でちょっとうわってなるのでかいつまんでメモ。

まずサンプルはこんな感じです。

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/e2e-az-name
            operator: In
            values:
            - e2e-az1
            - e2e-az2
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            values:
            - another-node-label-value
  containers:
  - name: with-node-affinity
    image: k8s.gcr.io/pause:2.0

requiredDuringSchedulingIgnoredDuringExecution がスケジューリング中のものに適用して、すでに実行済みのものは対象外だよ的な意味です。

matchExpressionskey の部分なのですが、node で describe 見るとわかりやすいです。 Labels: kubernetes.io/role=node とか記載があるはずです。もしくは、 kubectl get nodes --show-labels でもいいかもしれません(ちょっと見づらいですが)

例えば、 kubernetes.io/hostname を使えば指定したホスト名を持った node に pod を固めることもできます。ゾーンとかの方が使うのかな。

initContainers

公式ですが、ここをみるよりはこっちを見た方がわかりやすかったです。

サンプルは以下の通りです。

apiVersion: v1
kind: Pod
metadata:
  name: init-demo
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
    volumeMounts:
    - name: workdir
      mountPath: /usr/share/nginx/html
  # These containers are run during pod initialization
  initContainers:
  - name: install
    image: busybox
    command:
    - wget
    - "-O"
    - "/work-dir/index.html"
    - http://kubernetes.io
    volumeMounts:
    - name: workdir
      mountPath: "/work-dir"
  dnsPolicy: Default
  volumes:
  - name: workdir
    emptyDir: {}

emptyDir なので非永続化ボリュームを用意しています。それをまず initContainers で定義した busybox/work-dir にマウントして wget を利用して index.html を emptyDir に保存しています。nginx コンテナも workdir を /usr/share/nginx/html へボリュームマウントしていますので、先ほど保存した index.html が保存された状態であがってきます。Kubernetes の世界でクローズ出来ていいですね。使い所あるかな。

その他

ちなみに Kubernetes の基礎知識が足りてないな、知識ちゃんと保管したいな・・・って人は以下の参考書がオススメです。 かなり詳細にそして網羅されているので、これ一冊読んでおけば大丈夫です。電子書籍版もあります

Kubernetes完全ガイド (impress top gear)

Kubernetes完全ガイド (impress top gear)


シェアして頂けると嬉しいです。
参考になったという方がいれば是非お願いしますm(_ _ )m
モチベーション維持の観点で非常に励みになります。

このエントリーをはてなブックマークに追加

Kubernetes完全ガイド (impress top gear)

Kubernetes完全ガイド (impress top gear)

入門 Kubernetes

入門 Kubernetes

Docker/Kubernetes 実践コンテナ開発入門

Docker/Kubernetes 実践コンテナ開発入門

Kubernetes の dev 環境 では skaffold + kustomize が超便利な話。〜 CI/CD を考えてみた 〜

f:id:komeiy:20150107164847j:plain

Kubernetes の CD (継続的デリバリー)の話です。

Kubernetes って便利だなって思う反面、いちいちコンテナのイメージをビルドしたりプッシュしたり Kubetenetes へデプロイしたりするのが非常に面倒になってきました。みんなそうですよね。Dev 環境だけでも簡単にデプロイ環境作れないかなと思って色々試してみました。

ちなみに Kubernetes の基礎知識が足りてないな、知識ちゃんと保管したいな・・・って人は以下の参考書がオススメです。 かなり詳細にそして網羅されているので、これ一冊読んでおけば大丈夫です。電子書籍版もあります。

Kubernetes完全ガイド (impress top gear)

Kubernetes完全ガイド (impress top gear)

skaffold について

Google が開発している Kubernetes 向けの CD ができるツールです。特にサーバとかいらないのでお手軽に環境が作れます。

Kobito.GGXaP1.png

上記の図の通り、build, push, deploy の一連の流れを組むことができます。

https://github.com/GoogleContainerTools/skaffold

今回は、Dev 環境で skaffold dev を主に使っているのですが、一連の流れをコマンド一発で実現できますし、ログを垂れ流してくれるのが嬉しいですね。

kustomize について

Dev 用の yaml と Prd 用の yaml を生成するためにつかっています。 base に対して環境ごとの overlay を適用するため、以下のようなディレクトリ構造にしています。

├── base
│   ├── kustomization.yaml
│   ├── cert-secret.yaml
│   ├── deployment-app.yaml
│   ├── env-map.yaml
│   └── service.yaml
├── overlays
│   ├── development
│   │   └── kustomization.yaml
│   └── production
│       ├── kustomization.yaml
│       ├── service.yaml

以下のようなコマンドで development の yaml を生成しています。

kustomize build overlays/development/ > dev-k8s.yaml

環境準備

まずは skaffold をインストールします。MAC OSX だと以下の通りです。 特にサーバコンポーネントを入れる必要などはありません。

curl -Lo skaffold https://storage.googleapis.com/skaffold/releases/latest/skaffold-darwin-amd64 && chmod +x skaffold && sudo mv skaffold /usr/local/bin

次に skaffold のレポジトリをクローンします。

git clone https://github.com/GoogleContainerTools/skaffold

以下に各種設定ファイルがあります。

cd examples/getting-started

skaffold.yaml を見てみます。

Docker file を元にイメージをビルドして gcr にあげて、kubernetesk8s-pod.yaml を元にデプロイします。

次は以下のコマンドで実行してみます。

skaffold dev

docker build / docker push / kubectl apply が実行され、 Hello world! が表示されます。

[getting-started] Hello world!

さて、このまま main.go を書き換えてみましょう。再度一連の流れが走り、以下の通り出力が変わります。

[getting-started] Hello jerry!

skaffold の簡単な使い方とインストールは大丈夫ですね。 次に kustomize をインストールします。

brew install kustomize

kubernetes のデプロイ環境構築

skaffold も踏まえて以下のディレクトリ構造にしました。kubesec で復号化したファイルを元に kustomize でマニュフェストを生成しています。そのため、非暗号化テキストが入るため、manifest 配下を .gitignore に入れるようにしています。

├── README.md
├── base
│   ├── kustomization.yaml
│   ├── cert-secret.yaml
│   ├── deployment-app.yaml
│   ├── env-map.yaml
│   └── service.yaml
├── depoly_dev.sh
├── manifest
│   ├── dev-k8s.yaml
│   └── prd-k8s.yaml
├── overlays
│   ├── development
│   │   └── kustomization.yaml
│   └── production
│       ├── kustomization.yaml
│       ├── service.yaml
└── skaffold.yaml

Dev 環境のデプロイ

流れは以下の通りです。

- アプリケーションの更新
  -  skaffold dev を実行 -> Dockerfile(ないしは関連するファイル) の更新 -> 動作確認- > Dockerfile(ないしは関連するファイル) の更新 -> 動作確認
- kubernetes のマニュフェスト更新
  - skaffold dev を実行 -> マニュフェストの更新 -> 動作確認 -> マニュフェストの更新 -> 動作確認

ちなみに、アプリケーションと kubernetes のマニュフェストは別のレポジトリで管理しています。そのため、github submodule を使ってマニュフェスト側に取り込んでいます。

マニュフェストの生成部分を説明していなkったので説明しておきます。kustomize では、 base ないしは overlay、kustomization.yaml を更新してマニュフェストを生成します。

kustomize build overlays/development/ > dev-k8s.yaml

overlays/production/kustomization.yaml を見て見ます。namespace やファイルの頭、label に dev を一括で入れてくれます。image tag は base 側では指定せずにこちらで上書きします。

namespace: dev
bases:
- ../../base
namePrefix: dev-
commonLabels:
  env: dev
patches:
- service.yaml
imageTags:
- name: <private registry>/test-app
  newTag: "0.3"

あとは skaffold dev 叩けば OK です。

depoly_dev.sh は Kustomize や submodule 周りの処理をまとめたものです。 depoly_dev.sh を実行して必要な操作をワンコマンドで実行します。

Prd 環境のデプロイ

Prd では別のデプロイ方法を利用しています。 Devで気がすむまでテストをしているので、作業は少ないです。ある程度手作業を入れながら慎重に実施する方針で考えています。

少し話が逸れますが、 Prd 環境では Kustomize を利用してサービスも上書きしています。イメージを掴むためにサンプルを書いておきます。

apiVersion: v1
kind: Service
metadata:
  name: test-lb
spec:
  type: LoadBalancer
  ports:
    - name: "ldap-port"
      protocol: "TCP"
      port: 80
      targetPort: 80
  selector:
    app: test-subldap
apiVersion: v1
kind: Service
metadata:
  name: test-lb
spec:
  type: LoadBalancer
  loadBalancerIP: 10.10.10.10

本題に戻ります。image の作成には CircleCI を使っています。 tag がつくと CircleCI が docker registry に push するようにしています。

シンプルすぎてこれといってないですが、 .circleci/config.yml は以下の通りです。 本当はブランチの名前ごとに処理を分岐して CircleCI 側でもう少し処理するのが良いですね。

version: 2
jobs:
  build:
    docker:
      - image: circleci/golang:1.9.3
    working_directory: ~/app
    steps:
      - setup_remote_docker:
          docker_layer_caching: true
      - checkout
      - run:
          name: Build
          command: docker build -t ${IMAGE_NAME}:latest .
      - run:
          name: Tag to latest
          command: docker tag ${IMAGE_NAME}:latest ${OWNER}/${IMAGE_NAME}:$CIRCLE_TAG
      - run:
          name: Docker Login
          command: docker login -u ${DOCKER_USER} -p ${DOCKER_PASS} <private registry>
      - run:
          name: Push image to registory
          command: docker push ${OWNER}/${IMAGE_NAME}
workflows:
  version: 2
  build:
    jobs:
      - build:
          filters:
            branches:
              ignore: /.*/
            tags:
              only: /.*/

このような .circleci/config.yml になっているので、以下のように tag を push するとビルドが走るようになっています。Dev でテストして満足いったら tag つけるだけという感じです。

git tag 0.3
git push origin --tags

Kustomize で Prd 用のマニュフェストを生成して(これも Dev で検証しているので、共通の base ファイルは更新されている前提です)、kubernetes 側に適用します。

kubectl apply -f prd-k8s.yaml

一連の流れは bot 化しても良いかなと思いましたが、こなれてくるまで一旦手動にしています。

まとめ

kubernetes の CD はなかなかこれというのが見つからず、skaffold は割とシンプルで手元で試せるので面白かったです。一つ難点があるとすれば、手元のクレデンシャルに従って kubernetes にデプロイされるため環境間違いが怖いなというところです。spinnaker もいいかなと思いましたが、今回の環境にはオーバースペックかなと思ったので、また改めて機会をみてトライしてみようかなと思います。


シェアして頂けると嬉しいです。
参考になったという方がいれば是非お願いしますm(_ _ )m
モチベーション維持の観点で非常に励みになります。

このエントリーをはてなブックマークに追加

Kubernetes完全ガイド (impress top gear)

Kubernetes完全ガイド (impress top gear)

入門 Kubernetes

入門 Kubernetes

Docker/Kubernetes 実践コンテナ開発入門

Docker/Kubernetes 実践コンテナ開発入門

完全食・MRPなマイオプレックス1ヶ月飲んだら効果があったのでレビューしてみる

エンジニアの食生活的なお話です。 栄養とか体調には昔から凝ってまして、特にエンジニアは座りっぱなしだったり不規則な生活をすることが多いですし、コーラがぶがぶ飲んでる人とか多いですよね。それはさておき、業務時間でのパフォーマンスは健康体であることが非常に大きく関わるので、すごい大事って話です。

まず、MRPって何?ってところですが、置き換え食的なものです。 「Meal Replacement Powder」の略らしいです。

私はお昼ご飯をこれに変えてます。全部じゃないです。 週の2〜3をマイオプレックス+牛乳にしています。

f:id:komeiy:20181112121909j:plain

結論書いておきます。よかったのは以下の3点です。

  1. 自由な時間が増えた

  2. 体重が3キロくらい減った

  3. 節約になった

個別で解説しておきます。

1. 自由な時間が増えた

個人的な1番はこれです。自席周辺で全部済むので、かなり時間節約になります。 ニュースみながら 5 分くらいで済みます。あとは洗う時間だけです。 ちなみにこの記事も時間ができた昼休みに書いています。

メリハリが欲しい性格なので、情報収集などは休憩中にまとめて業務時間には集中して一つのことに専念したりしたいです。(現実問題難しいけど)

こういう自分で自由に過ごせる時間が増えるのは想像以上にいいことだと思います。

2. 痩せた(体重が3キロくらい減った)

ダイエットをするつもりはなかったのですが、おおよそ3キロくらい平均落ちました。元々体重は平均より少ないのです。 運動したりもしますし人一倍食生活は好きで気を遣っているので色々要因はあるかもしれませんが、3キロのうちの大半はこれが寄与していると思います。気を遣っていると言いましたが、月に1〜2回ほど二郎インスパイアのラーメン食べたりもしますし、毎日ピリピリして摂生しているわけではないです。

  • マイオプレックス+ローソンの低脂肪乳(厳密には牛乳じゃない)
  • マイオプレックス(ハーフ)+ローソンの低脂肪乳+甘栗

こんな感じで適当に組み合わせてその日の気分で運用してます。

3. 節約になった

iHerbで買うと一食分のマイプレックスが260円くらいです。 為替によって変動しますが、5200円 - 5500円くらいで20食分です。 そこに 5% 引きのクーポン QIG949 を入れるとそれくらいになります。

ちなみにマイオプレックスの購入はこちらです ※ 2019年2月追記: 売り切れっぽいですね。。

その他

あと個人的に良かったなと思う点を何個か。

a. 昼食後の眠気が来たりはほとんどないです。

もともとそんなにないですが、ほぼ皆無って感じです。安定しているイメージです。 1. で書きましたがある程度時間も創出できますしとても良いです。

昼ごはんダラダラ食べる -> 食後眠い なサイクルと比べると日々の積み重ねではだいぶ時間が変わります。

b. たまに食べる普通の昼ごはんが美味しい

週2から3にしているのは、やっぱり誰かとお昼食べたかったりするのでそうしいてるのですが、毎日だとまたここか的な飽きもあるのですが、久しぶりにいくとかなり美味しく感じます。最高です。

c. 腹持ち

これもよく聞かれますが、実は半分で十分なので全部飲んでないです。その場合、だいたい正午にたべて夕方5時くらいまではもつイメージです。適当におやつ食べます(ちゃんとしたもの)。食事は小分けの方が好きなので悪くないです。

d. 栄養素について

公式ページに書いてます。

こうしてみるとビタミンB1・B2入ってないんだとか発見もありますが、割とまんべんなく入っていると思います。わかると思いますが全食置き換えでなくて、ちゃんと別のタイミングでもまんべんなく取るべきです。

ちなみに、COMPとの比較はこちらがとてもわかりやすかったです。

完全栄養食品・MRPの比較 | 完全食(完全栄養食)

マイプレックスの購入先について

iHerb から買いました。こちらです。味はチョコレートを買いました。海外ですが1週間くらいで届きました。プロテインとかもあるのでここでまとめて買ってます。

割高になりますが、Amazon でも売ってます。

売り切れのようなので代替えだとこちらですかね。

Kentai(ケンタイ) MRP PRO 65g*10袋

Kentai(ケンタイ) MRP PRO 65g*10袋

まとめ

色々書きましたが、一番大きかったのは時間のゆとりです。 これの商品を毎日絶対食べるっていうのはオススメはしませんが、使い方次第ではかなり有益なものだと思います。

頑張りすぎず日々の生活に少しでも取り込めると良いエンジニアライフが送れるのでは?


シェアして頂けると嬉しいです。
参考になったという方がいれば是非お願いしますm(_ _ )m
モチベーション維持の観点で非常に励みになります。

このエントリーをはてなブックマークに追加

Kubernetes v1.11 を scratch install したら理解深まるじゃんって話

kubeadm とか使わずに Kubernetes を構築するって大変ですよね。 ただ、一から構築することで学ぶことがあると教わりまして重い腰をあげて構築してみました。

結論として順番に組み立ててくと理解深まります。できればハマった方がいいので手順は書きますが、 バージョン変えたりしてハマってみてください。

事前準備

ドキュメントを読む

公式ドキュメントは以下の通りです。予備知識なしでこの通りに進めるのは難しいかなと思いますが、 読んでおくといいです。

https://kubernetes.io/docs/setup/scratch/

頭に構成を描いておく

kubelet がいて api server がいてとかの概要図は以下を見てイメージしておくといいと思います。

f:id:komeiy:20180828184915p:plain公式 から引用

構築環境

今回、VM 上に作成しようと思います。物理サーバでもいいですし何らか構築環境を準備してください。 Master Node 1台、Regular Node (公式曰くこう呼ぶらしい。Minions ではないのかな)を 1台の構成でいきます。

ちなみに公式ドキュメントによると以下の構成で構築するようです。

Nodes

・You can use virtual or physical machines. ・While you can build a cluster with 1 machine, in order to run all the examples and tests you need at least 4 nodes. ・Many Getting-started-guides make a distinction between the master node and regular nodes. This is not strictly necessary. ・Nodes will need to run some version of Linux with the x86_64 architecture. It may be possible to run on other OSes and Architectures, but this guide does not try to assist with that. ・Apiserver and etcd together are fine on a machine with 1 core and 1GB RAM for clusters with 10s of nodes. Larger or more active clusters may benefit from more cores. ・Other nodes can have any reasonable amount of memory and any number of cores. They need not have identical configurations.

サーバセットアップ

今回は VM を使います。 16.04.5 LTS を利用しています。

今回は、 hosts ファイルにそれぞれのサーバを登録しておきました。

net.ipv4.ip_forward を 1 にしておきます。忘れると意外と気づかないハマりポイントなので気をつけてください。

dokcer install

以下を参考にしておくと良いかと思います。 18.06.0-ce をインストールしました。

https://docs.docker.com/install/linux/docker-ce/ubuntu/#install-docker-ce

kubernetes の バイナリ を install

ここからが本題です。ちなみに SSL なしで構築します。

以下から kubernetes.tar.gz をダウンロードします。 本記事では v1.11.2 を入れています。 URL は latest にしています。

https://github.com/kubernetes/kubernetes/releases/latest

適当な場所に落としてください。後々バイナリだけ取り出します。

$ wget https://github.com/kubernetes/kubernetes/releases/download/v1.11.2/kubernetes.tar.gz

公式マニュアルにもありますが、./kubernetes/server 配下のファイルを解凍してください。

Download the latest binary release and unzip it. Server binary tarballs are no longer included in the Kubernetes final tarball, so you will need to locate and run ./kubernetes/cluster/get-kube-binaries.sh to download the client and server binaries. Then locate ./kubernetes/server/kubernetes-server-linux-amd64.tar.gz and unzip that. Then, within the second set of unzipped files, locate ./kubernetes/server/bin, which contains all the necessary binaries

kubelet や kube-proxy などバイナリ一式 /usr/local/bin へ移動しておきます。 kube-apiserver など master でのみ必要なものもありますが、分類が手間なので一式移動してしまいます。

kubetlet

kubelet は pod を起動し管理する役割を持っています。docker と apiserver の間にいるイメージです。 まずはそのことを理解をするため、Node に単体で動かしてみます。ここでは apiserver を指定しません(まだいないのですし)

nginx を起動するマニュフェストを kubelet に読み込ませて起動します。

$ kubelet --runtime-cgroups=/systemd/system.slice --kubelet-cgroups=/systemd/system.slice --pod-manifest-path /tmp/nginx.yaml &> /tmp/kubelet.log &

runtime-cgroups の部分ですが、Failed to get system container stats for のようなエラーが出たため、こちらを参考にいれています。

さて、docker コマンドで見てみましょう。nginx のコンテナできてますね。

$ docker ps -a
CONTAINER ID        IMAGE                  COMMAND                  CREATED             STATUS              PORTS               NAMES
1f979d3281fb        nginx                  "nginx -g 'daemon of…"   3 minutes ago       Up 3 minutes                            k8s_nginx_nginx-komei-k8s-master_default_8041421870561284c2290a9297f98428_0
06786bd7d802        k8s.gcr.io/pause:3.1   "/pause"                 3 minutes ago       Up 3 minutes                            k8s_POD_nginx-komei-k8s-master_default_8041421870561284c2290a9297f98428_0

docker inspect を叩い て ip アドレスを覗き見してみます。直接 curl でアクセスするとデフォルトページが出てくるはずです。

# curl 192.168.99.2
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>

kube-apiserver

api server は名前の通りですが、kubectl を叩いた時や kubelet など各コンポーネントとの通信を受け付けます。 ここから master を組み立てていきます。

etcd

etcd が必要となりますのでインストールします。

$ wget https://github.com/coreos/etcd/releases/download/v3.3.9/etcd-v3.3.9-linux-amd64.tar.gz
$ tar xzvf etcd-v3.3.9-linux-amd64.tar.gz
$ cd etcd-v3.3.9-linux-amd64
$ cp etcd* /usr/local/bin/

次に起動します。

$ etcd --listen-client-urls http://0.0.0.0:2379 --advertise-client-urls http://<master ip address>:2379 &> /tmp/etcd.log &

etcdctl を使って起動確認しておきます。

$ etcdctl cluster-health
member 8e9e05c52164694d is healthy: got healthy result from http://<master ip address>:2379
cluster is healthy

一応、 ss -ltn で 2379 が開いていることも確認しておくと良いでしょう。

kube-apiserver

kube-apiserver のバイナリはすでに配置していますので、起動するのみです。 オプションで先ほど渡した etcd を渡します。service-cluster-ip-range はその名の通りですが、kubernetesクラスタ内でのみ疎通が可能な ClusterIP の払い出しレンジを設定しています。admission-control は off にしています(後述)

$ kube-apiserver --etcd-servers=http://localhost:2379 --service-cluster-ip-range=192.168.199.0/24 --bind-address=0.0.0.0 --admission-control="" --insecure-bind-address=0.0.0.0 &> /tmp/apiserver.log &

それでは起動確認をしてみましょう。自身の 8080 へアクセスしてみます。

$ curl http://localhost:8080/api/v1/nodes
{
  "kind": "NodeList",
  "apiVersion": "v1",
  "metadata": {
    "selfLink": "/api/v1/nodes",
    "resourceVersion": "37"
  },
  "items": []
}

まだ node がいないですね。Node 側で kubelet に apiserver の値を設定してもう一回起動してみます。 ちなみに、 --api-servers は利用できなくなっているので、以下のように kubernetes.conf を利用してみます。

$ cat /etc/kubernetes/kubelet.conf
apiVersion: v1
clusters:
- cluster:
    server: http://<master ip address>:8080
kind: Config
preferences: {}
users: []
$ 
$ kubelet --runtime-cgroups=/systemd/system.slice --kubelet-cgroups=/systemd/system.slice --kubeconfig=/etc/kubernetes/kubelet.conf &> /tmp/kubelet.log &

では同じように curl を叩いてみましょう。node が出力されるはずです。 /etc/kubernetes/kubelet.conf と同様の内容を ~/.kube/config に設定して kubectl を叩いてみます。

$ kubectl get nodes
NAME                STATUS    ROLES     AGE       VERSION
komei-k8s-node01   Ready     <none>    16s       v1.11.2

$ Master でも kubelet を起動して確認してみます。

$ kubectl get nodes
NAME                STATUS    ROLES     AGE       VERSION
komei-k8s-master   Ready     <none>    23s       v1.11.2
komei-k8s-node01   Ready     <none>    9m       v1.11.2

kubectl get nodes が出てきましたが、 service を作ったり pod を起動したり kubernetes を利用する上での操作は理解しているものとして記載しています。ちなみに以下の参考書を一式やってみるとこのあたりは理解できると思います。

入門 Kubernetes

入門 Kubernetes

kube scheduler

スケジューラは pod をどのノードに配置するのかを決める役割を持っています。 こちらもバイナリは配置済みなので起動だけします。

$ kube-scheduler --master=http://localhost:8080 &> /tmp/scheduler.log &

controller mangaer

Replication Controller や Service Account を管理します。これで master がほぼ完成です。 おそらくこれを立てる前に Service Account を見ても default がないはずです。

こちらも起動のみです。

$ kube-controller-manager --master=http://localhost:8080 &> /tmp/controller-manager.log &

同時に service account も作られます。

$ kubectl get serviceaccounts
NAME      SECRETS   AGE
default   0         42s

ちなみに admission-control を off にしておいたのは以下のようなエラーが出るのを避けるためです。

$ kubectl create -f /tmp/nginx.yaml
Error from server (ServerTimeout): error when creating "/tmp/nginx.yaml": No API token found for service account "default", retry after the token is automatically created and added to the service account

この辺りを読んでおくと良いと思います。

Managing Service Accounts - Kubernetes

no API token found for service account default/default, retry after the token is automatically created and added to the service account · Issue #33714 · kubernetes/kubernetes · GitHub

それでは pod がうまく起動したことを確認してみましょう。 ただ、無事に pod が立ったのに cluster ip でアクセスできないですよね?

ここからネットワーク周りを組み立てていきます。

kube-proxy

まさにという感じですね。Node にインストールします。

$ kube-proxy --master=http://<master ip address>:8080 &> /tmp/proxy.log &

ip a とか ip r すればわかりますが、これでも cluster ip へ疎通できる気がしないですね。

flannel

flannel です。Container Networking Interface (CNI) です。

今回、v0.10.0 を利用します。以下から落として例によってパスが通った場所へ配置します。

https://github.com/coreos/flannel/releases/download/v0.10.0/flannel-v0.10.0-linux-amd64.tar.gz

そして、flannel の設定を etcd へ設定します。

$ etcdctl mk /flannel/network/config/  '{"Network":"192.168.200.0/23"}'

flannel を起動します。

$ flanneld -ip-masq -kubeconfig-file /etc/kubernetes/kubernetes.conf --proxy-mode=iptables -etcd-endpoints=http://<master ip address>:2379 -etcd-prefix=/flannel/network &> /tmp/flanneld.log &
$ mkdir -p /etc/cni/net.d /opt/cni/bin/

以下の通り cni の plugin を一式配置します。

$ wget https://github.com/containernetworking/cni/releases/download/v0.6.0/cni-amd64-v0.6.0.tgz
$ wget https://github.com/containernetworking/plugins/releases/download/v0.7.1/cni-plugins-amd64-v0.7.1.tgz
$ cd /opt/cni/bin
$ tar xzvf /tmp/cni-amd64-v0.6.0.tgz
$ tar xzf /tmp/cni-plugins-amd64-v0.7.1.tgz

設定も入れておきます。

$ cat /etc/cni/net.d/flannel.conf
{
    "name": "podnet",
    "type": "flannel",
    "delegate": {
        "isDefaultGateway": true
    }
}

pod に使ってもらわないと意味がないので、conf と plugin の path を kubelet に渡します。 以下のオプションをつけて kubelet を起動し直します。

--network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin

すると cni0 がインタフェースとして作成され、pod で利用する veth の master が cni0 になります。

34: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1472 qdisc noqueue state UP group default qlen 1000
    link/ether 5a:ba:f0:7b:79:96 brd ff:ff:ff:ff:ff:ff
    inet 192.168.201.1/25 scope global cni0
       valid_lft forever preferred_lft forever
35: veth2005db1c@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1472 qdisc noqueue master cni0 state UP group default
    link/ether 6a:2d:31:c9:ee:cd brd ff:ff:ff:ff:ff:ff link-netnsid 0

ちなみに docker 周りなど systemctl daemon-reload かけて restart しないと反映されない箇所を触った場合は適宜実施してください。

動作確認

ここまでくるともう完成です。 ClusterIP で接続できますよね。 次に、Node Port で service を作ってみましょう。以下のようにアクセスできるはずです。

curl <node ip address>:30073
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

まとめ

どうでしょうか?実際は理解が甘くてつまづいたりする箇所がありました。 バージョンが変わるとオプションが変わったりしますので、一度つまづいてみると理解が深まると思います。

まずは kubernetes を利用する側を勉強してみて、cluster を立てるという順番にで学習しました。 利用する部分は実際に実務で関われると良いと思いますが、機会がなければまずは網羅性の高い参考書を一冊やってみるとかなり理解は深まると思います。


シェアして頂けると嬉しいです。
参考になったという方がいれば是非お願いしますm(_ _ )m
モチベーション維持の観点で非常に励みになります。

このエントリーをはてなブックマークに追加

入門 Kubernetes

入門 Kubernetes

Docker実践ガイド impress top gearシリーズ

Docker実践ガイド impress top gearシリーズ

Kubernetes完全ガイド (impress top gear)

Kubernetes完全ガイド (impress top gear)

CDH5のでHadoopクラスタをインストールする

CDHとは

CDH は Apache Hadoop や関連製品を含む Cloudera のソフトウェアディストリビューションです。 Apache Flume や Hive や Spark、Kudu なども含みます。

CDH のおかげでとても簡単に環境を構築することが可能です。ただし、癖がある部分もありしっかりと手順を抑えておき、 やり直しがないようにしておく必要はありそうです。

ちなみに最近では EMR や Dataproc などもあるため自前で構築することは少し減ってきたかもしれません。 実際に裏で何をしているか理解するために、構築し冗長化をしてみたり触っていくことで内部を理解することも大事かもしれません。

Hadoopをインストール

事前知識

以下の参考書が基礎知識の習得にはよいと思います。日本語で書かれています。

Hadoopオペレーション ―システム運用管理ガイド

Hadoopオペレーション ―システム運用管理ガイド

サーバの準備

今回、サーバを5台用意しました。HDFS と YARN の NameNode は後ほど冗長化します。 以下のスペックで用意しました。よく OOM になるのでメモリはそれなりに必要です。

CPU: 8core
Memory: 32GB
SSD: 100GB
OS: CentOS7
  • すべて名前解決できる状態にしておきます。今回は hosts を全台に記載しておきます。

/etc/hosts /etc/hostname

  • 時刻はすべて NTP と同期しておきます

  • yum update でパッケージを最新にしておきます

  • 各サーバに鍵認証かパスワードで SSH ログインできる環境を作っておきます

  • swap と transparent hugepages の調整

以下のような警告がでます。調整しておくと良いと思います。

/proc/sys/vm/swappiness を最大値の 10 に設定することをお勧めします。現在の設定は 30 です。sysctl コマンドを使用して、この設定を実行時に変更します。この設定が再起動後に保存されるよう /etc/sysctl.conf を編集します。インストールは続行できますが、スワッピングが原因でホストの状態に問題が発生したと Cloudera Manager からレポートされる可能性があります。以下のホストが影響を受けます

$ echo 10 > /proc/sys/vm/swappiness

恒久的には以下の対応を入れてください。

vm.swappiness = 10
$ echo never > /sys/kernel/mm/transparent_hugepage/defrag
$ echo never > /sys/kernel/mm/transparent_hugepage/enabled

こちらも同じように恒久的には rc.local などに記載をしておきます

echo never > /sys/kernel/mm/transparent_hugepage/defrag
echo never > /sys/kernel/mm/transparent_hugepage/enabled

インストール

以下、サーバ1台 で作業します。インストーラが立ち上がりますので、Next で次へ進んでいきます。

$ cd /tmp
$ curl -O http://archive.cloudera.com/cm5/installer/latest/cloudera-manager-installer.bin
$ chmod +x cloudera-manager-installer.bin
$ ./cloudera-manager-installer.bin

CDH セットアップ

インストールが終わったら、対象サーバの 7180 ポートへアクセスします。 ポートが開くまで時間がかかると思います。

PEnYAx.png

初期パスワードは admin / admin です。

QrMa4v.png

ライセンスに同意して続けます。

ORvHcd.png

今回はサポートなどは必要ありませんので、Express 版を利用します。

IEgCHI.png

このまま続けます

Lo5F4U.png

IPアドレスを記載してスキャンします

rhflLC.png

SSH が可能なユーザと鍵(もしくはパスワード)を設定します

SoMXEr.png

3Le47a.png

parcel によって全サーバに展開されます

VUJvGR.png

今回は、コア Hadoop でインストールします

YbcfJa.png

各サーバに割り当てるロールを選択します

abX7R0.png

今回、データベースは組み込みの PostgreSQL を利用します

Kobito.iQwE5j.png

セットアップが進みます。名前解決に問題があるまま進んでいるとここで大コケします

Kobito.iaJdUP.png

問題なければセットアップが完了します。

Kobito.MVlLQE.png

管理画面です。

次回は NameNode の冗長化を書きたいと思います。


シェアして頂けると嬉しいです。
参考になったという方がいれば是非お願いしますm(_ _ )m
モチベーション維持の観点で非常に励みになります。

このエントリーをはてなブックマークに追加

Hadoop徹底入門 第2版 オープンソース分散処理環境の構築

Hadoop徹底入門 第2版 オープンソース分散処理環境の構築

はじめてのHadoop ~分散データ処理の基本から実践まで

はじめてのHadoop ~分散データ処理の基本から実践まで