とあるインフラエンジニアの日常

インフラ、ネットワークに囲まれた日常をつらつらと書いていきます。時々旨い酒

nginx unitを試してみたら面白かった件

みなさんこんにちは

前回はprometheusを試していて、まだ全然postしおわってないのですが、こんなニュースが入ってきたので飛びついてしまいました。

www.publickey1.jp

nginx unitとは?

nginxのソフトウェア開発チームが実装した、Webアプリケーション・サーバーで、下記のような特徴があります。

  1. たくさんの言語に対応したWebアプリケーション・サーバー(php, python, go, java, node.js)
  2. バージョンアップのシームレスな実行
  3. REST APIを経由したconfig

個人的に特に気になったのが3番。jsonREST APIで設定を投入できるというのはdevelperでも設定の敷居が下がりそうだなーって思いました。 公式のドキュメントを読む限りでも、nginxのバックエンドに配置する用途を想定しているようです。

インストール

今回は手間を省くために、公式サイトにある通りリポジトリを登録してyumでインストールしました。 http://unit.nginx.org/docs-installation.html#precompiled-packages

実際に使ってみた with python

flaskで作成したpythonのプログラムを動かしてみます。

設定の作成

unitにはApplicationとListenerという2つの重要な概念があるので、それぞれ設定を進めていきます。

  • Applicationはアプリケーションごとに、使用する言語やドキュメントルートなどの設定を定義するブロックです。
  • Listenerはどのようなポートでどのアプリケーションを待ち受けるかを定義します。

最終的に完成した設定はこちらです。

start.json

{
        "listeners": {
                "*:8300": {
                        "application": "my_python"
                }
        },

        "applications": {
                "my_python": {
                        "type": "python",
                        "workers": 10,
                        "path": "/var/www/mypython",
                        "module": "wsgi"
                }
        }
}

この設定内容は下記と同じ意味です。

  • /var/www/myphthon/wsgi.pyに作成されたWSGIアプリケーションmy_pythonを定義
  • アプリケーションの待受ポート8300にpy_pythonを割り当てる

設定の反映(APIで送信)

設定の作成が完了したので、実際に投入してみたいと思います。 最初に、APIを送るためにsystemctl start unitdでunitのサービスをUPしておきます。

次に、下記コマンドで設定ファイルをpost.

curl -X PUT -d @start.json --unix-socket /run/control.unit.sock http://localhost/

設定が反映されているか、getで確認。

curl --unix-socket /run/control.unit.sock http://localhost/

下記のように設定ファイルが表示されたら成功しています。

[root@fluentd-with-apache ~]# curl --unix-socket /run/control.unit.sock http://localhost/
{
        "listeners": {
                "*:8300": {
                        "application": "my_python"
                }
        },

        "applications": {
                "my_python": {
                        "type": "python",
                        "module": "wsgi",
                        "workers": 10,
                        "path": "/var/www/mypython"
                }
        }
}

動かしてみる

最後に、適当なWSGIアプリケーションを作成して、実際にその結果を確認してみましょう。今回は下記のようなかんたんなプログラムにしました。 /var/www/mypython/wsgi.py

#!/usr/bin/env python

from flask import Flask

application = Flask(__name__)

@application.route("/")
def index():
    return "nginx with python"

これで、実際にアクセスしてみるとこんな感じで動くことがわかりました。

http://localhost:8300/ f:id:kurokiyokiyo:20170910215443p:plain

実際に使ってみた with php

基本はPython(wsgi)と同じ。下記のようにPHP用の設定を入れてあげれば動作する

{
        "listeners": {
                "*:8300": {
                        "application": "my_python"
                },
                "*:8400": {
                        "application": "my_php"
                }
        },

        "applications": {
                "my_python": {
                        "type": "python",
                        "module": "wsgi",
                        "workers": 10,
                        "path": "/var/www/mypython",
                },
                "my_php": {
                        "type": "php",
                        "workers": 10,
                        "root": "/var/www/html",
                }
        }
}

使ってみて気になったところ(memo)

今回使ってみた結果、非常にわかりやすくおもしろかったです。 下記の通り色々発展途上なところがありましたが、設定で回避できるところもあるかもしれないので調べて行きたいと思います。

  • サービスをrestartするたびに設定が揮発するので、serviceをstartする際に設定をpostする必要がある
  • wsgiが格納されている変数名画applicationじゃないと動作しない
    • 変数名appだとtimeoutになってしまった
    • 変更オプションとかあるか調べようと思う
  • pyenvが使えない(←超重要
    • システムのpythonを触って壊したりしたくない。。。。。。(systemのpythonでpipとかキケン)

Prometheusを試してみた。 その1

おひさしぶりです。

皆さんお久しぶりです。色々あって今はネットワーク機器を触りながら運用監視ツールを色々試しています。

そんな中でここ数年話題の監視ツールPrometheusを試したので紹介してみます。

Prometheusとは

Prometheusとはgoogleの監視システムに触発されて、soundcloudのエンジニアが開発した監視ツールで、下記のような特徴があります。

  • Prometheusからデータを取得に行くpull型の監視システム
  • 監視対象にはExporterと呼ばれるアプリをlistenさせておいて、Prometheusがそこにアクセスする
  • goで書かれているため1バイナリをダウンロードして設定を投入だけで使える
  • PromQLを利用して、様々なクエリーをかんたんに書くことができる。
  • Graphanaとの連携で、視覚化が容易にできる。
  • Alertの抑止機能が豊富

https://prometheus.io/

Prometheus関連の大まかなアーキテクチャ

Prometheus自体がしていることはメトリクスを取得→ストレージへの格納を行っているだけです。 GUIやアラート時の通知機能などはwebUIやAlertmanager, pushgatewayなどのモジュールと連携を行うことで実現しています。

f:id:kurokiyokiyo:20170903221606p:plain

https://prometheus.io/docs/introduction/overview/

インストール

今回はGCP上のCentOS7.3に構築を進めていきます。

#download
wget https://github.com/prometheus/prometheus/releases/download/v1.7.1/prometheus-1.7.1.linux-amd64.tar.gz

#解凍
tar zxvf prometheus-1.7.1.linux-amd64.tar.gz

# prometheusを実行ディレクトリに移動
mv prometheus-1.7.1.linux-amd64/prometheus /usr/local/bin/

動かしてみる

かんたんなconfigを作って試してみる。 下記はprometheusが導入されているサーバーのみ監視対象にする設定になる(ダウンロードしたフォルダ内のsimple.ymlを元にすると楽)

vi /etc/prometheus.yml

# my global config
global:
  scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
  # scrape_timeout is set to the global default (10s).

  # Attach these labels to any time series or alerts when communicating with
  # external systems (federation, remote storage, Alertmanager).
  external_labels:
      monitor: 'codelab-monitor'

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  # - "first.rules"
  # - "second.rules"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
  - job_name: 'prometheus'

    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.

    static_configs:
      - targets: ['localhost:9090']

上記設定を作成後、下記コマンド実行。ブラウザでアクセスするとPrometheusの管理画面が参照可能。

prometheus --config.file=/etc/prometheus.yml

f:id:kurokiyokiyo:20170903224619p:plain

Status→targetsで監視対象がUpしているかどうかを確認できる。 f:id:kurokiyokiyo:20170903224718p:plain

GraphからPrometheusにクエリを投入して、データを確認することができる。 f:id:kurokiyokiyo:20170903224947p:plain

毎回起動するのは大変なので。。。

毎回手動でコマンドを入力するのは大変なので、systemctlから起動できるよう、serviceに登録してしまいましょう。

vi /lib/systemd/system/prometheus.service

[Unit]
Description=Prometheus service
After=syslog.service prometheus.service

[Service]
Type=simple
ExecStart=prometheus --config.file=/etc/prometheus.yml
PrivateTmp=true

[Install]
WantedBy=multi-user.target

上記を保存したあと、下記のコマンドで起動できるはず。

# 自動起動を有効
systemctl enable prometheus
# prometheus実行
systemctl start prometheus

次回はnode_exporterを導入して、実際にクエリを書いて見ようと思います。

SRX100なれはじめ その5(sourceNATの設定)

インターネットにアクセスする際、プライベートIPのままアクセスすることはあまりないと思います。
今回は、アドレスを変換するNAT(SourceNAT)の設定をしたいと思います。

NATの設定

JunOSではNATの設定をセキュリティポリシーやインタフェースの設定から独立して取り扱います。
実装されているNATは下記の3種類になります。

  • SourceNAT・・・送信元IP/ポート番号の変換(screenOSにおけるInterfaceNAT, インターネットアクセスの際などに使われる)
  • DestinatonNAT・・・送信先IP/ポート番号の変換(ScreenOSにおけるVIP/DIP, 1個のグローバルIP複数のサーバーを公開する場合などに使用)
  • StaticNAT・・・IPアドレス同士を1対1で変換する(ScreenOSにおけるMIP, 1個のグローバルIPで1台のサーバーを公開するなどで使用)

NAT設定がポリシーベースではなくなったため戸惑います。今回はSourceNATを設定したいと思います

SourceNATの構成

f:id:kurokiyokiyo:20150927195920p:plain
* 前回のconfigに追記して設定します

sourceNATの設定

  • 設定の流れ

    • ルールセットの作成
    • ルールセット内にルール(適用条件/アクション)を設定
  • ルールセットを作成して送信元、宛先zoneを設定します

[edit]
# ルールセット"trust-to-untrust"の作成
root# set security nat source rule-set trust-to-untrust
# ルールセット"trust-to-untrust"は送信元がtrust、送信先がuntrustゾーンの場合適用する
root# set security nat source rule-set from zone trust
root# set security nat source rule-set from to untrust
  • ルールの設定
[edit]
#ルールセット内にRule1を作成
root# set security nat source rule-set rule Rule1
#送信元アドレス192.168.1.0/24をsourceNATの対象にする
root# set security nat source rule-set rule Rule1 match source-address 192.168.1.0/24
# 条件に一致して、アドレス変換する際はルーターの送信側インタフェースにIPアドレスを変換する
root# set security nat source rule-set rule Rule1 then source-nat interface

確認方法

下記のコマンドにて、NATのアドレス変換がされていることが判ります。

root> show security flow session 
Session ID: 151, Policy name: trust-to-untrust/4, Timeout: 1198
  In: 192.168.1.2/49206 --> 108.160.172.236/443;tcp, If: vlan.0
  Out: 108.160.172.236/443 --> 192.168.0.101/64189;tcp, If: fe-0/0/0.0

Session ID: 188, Policy name: trust-to-untrust/4, Timeout: 1268
  In: 192.168.1.2/49221 --> 54.192.110.117/443;tcp, If: vlan.0
  Out: 54.192.110.117/443 --> 192.168.0.101/57083;tcp, If: fe-0/0/0.0

Session ID: 189, Policy name: trust-to-untrust/4, Timeout: 1268
  In: 192.168.1.2/49222 --> 54.192.110.117/443;tcp, If: vlan.0
  Out: 54.192.110.117/443 --> 192.168.0.101/30567;tcp, If: fe-0/0/0.0

Session ID: 193, Policy name: trust-to-untrust/4, Timeout: 1206
  In: 192.168.1.2/49224 --> 108.160.172.193/443;tcp, If: vlan.0
  Out: 108.160.172.193/443 --> 192.168.0.101/14173;tcp, If: fe-0/0/0.0

Session ID: 199, Policy name: trust-to-untrust/4, Timeout: 1768
  In: 192.168.1.2/49232 --> 108.160.163.100/443;tcp, If: vlan.0
  Out: 108.160.163.100/443 --> 192.168.0.101/10113;tcp, If: fe-0/0/0.0

次の記事はSRXを離れてJenkinsのことでも書こうと思っています。
(意訳: PPPoEの設定がうまくできない・・・・orz)

参考

Juniper Networks NAT http://www.juniper.net/assets/jp/jp/local/pdf/others/nat.pdf

IT勉強会で懇親会をするとき気をつけること

これまで、江戸前セキュリティ勉強会まっちゃ445勉強会を中心に、IT勉強会で懇親会の担当をする機会に多く恵まれてきました。
その中で、懇親会を企画する際に、気をつけたほうがいいと思ったこと、これまでうまくできなかったことを、
参画から5年(もうすぐ6年)の節目で、一度まとめておきたいと思います。
色々と教えて頂いたid:ripjyr id:vulcainに多謝!

予約者数

  • 勉強会参加者の6割が入る箱を探す
    • (9/23追記)上記人数は規模に応じて想定割合は変更する。上記の数字は勉強会出席者が100人の場合の想定
    • (9/23追記)下記は一例(勉強会参加者が多いほど人数が読みづらいけど、多いほど懇親会出席率は低くなる傾向があると思う)
      • 勉強会参加者< 70人 → 0.7-0.8
      • 勉強会参加者> 100人 → 0.55くらい(少し少なめ)
  • 当日になってキャンセルが出るのは日常。経験則では5-10%程度
    • (9/27追記)事前にリマインダを送付して、当日キャンセルを防ぐ
      • 忘れている人、予定が変わった人は往々にして発生するので
      • 特に、年度末は予定外タスクが発生してドタキャンが多いので注意
      • できれば、1週間前,直前の2回くらい送付しておくと良い
    • 最初は、勉強会参加者数*0.6*0.85くらいの人数で席を予約、少し様子を見てから人数を増やすようにしている
    • お店のご厚意で、懇親会Z日前までなら人数減OKの場合は、逆に勉強会参加者数*0.6*0.9で予約して、ギリギリまで人数を調整している

会場の選定

  • チェーン店はなるべく使わない。使ってもあまり大規模展開していない店を選ぶ(話題性に欠ける)
  • 会場からの移動距離がなるべく少なく、道がわかりやすい店舗が好ましい
  • 上記のような都合の良い店舗がない場合は、地図を配布するなどフォローしきれるか検討する
続きを読む

SRX100なれはじめ その3(基本的なルーター構築)

今回から、簡単なルーターの構築をしていこうと思います。 デフォルトに近い構成なので、半分デフォルトconfigの解説になりそうですがあしからず。

f:id:kurokiyokiyo:20150920195926p:plain

構成

  • IPアドレスは右記、Trust(fe0/0/0): 192.168.1.1/24, Untrust(fe0/0/1-7): 192.168.0.101/24
  • 上流のゲートウェイは192.168.0.1
    • 上流には、192.168.1.0のゲートウェイが192.168.0.101であることは設定済みとする
  • 定義するゾーンは標準のTrust, Untrustのみ
  • Trust → Untrustへの通信はすべてaccept
  • Untrust → Trustの通信はすべてDiscard(deny)
続きを読む

SRX100なれはじめ その2(基本的な操作)

コマンドの練習に設定をいろいろいじってみたいと思います。

設定の確認

オペレーショナルモードでshow configを実行することで現在の設定を確認することができます。

設定の追加・削除

JunOSの設定は階層構造で保存されています。 例えば、下記の標準のVLAN設定を編集したいとします。

vlans {
    vlan-trust {
        vlan-id 3;
        l3-interface vlan.0;
    }
}
続きを読む

SRX100なれはじめ その1(初期設定)

実際にSRX100を開梱して、設定準備をした際のことです。  

続きを読む