set setting reset

インフラ関連の小ネタと備忘録

de:code 2016 5/25 メモ

de:code 2016 5/24 メモ - set setting reset の続きです。

powershell

DSC

  • コード書く
  • mof ファイルができる
  • これを送って実行させる
    • start-dscconfiguration
  • LCM
    • local configuration manager
  • push は windows から実行
  • pull server
    • http だけでなく smb でも ok
    • 各ノードが server にポーリングする
    • CA を使って https 通信可能
    • 運用を dsc に寄せることもできる
  • Azure Automation

Docker と containter service

  • windows container の話ナシ
  • mesos + swarm
  • microservice architecture
  • 開発、移動、実行するプラットフォーム
  • linux kernel
    • namespace
      • リソースの分断
    • cgorup
      • リソース管理 *コンテナ技術の標準化団体がある
  • docker が実現したこと
    • software が必要な全てをファイルシステムに包む
    • どのような環境でも実行を保証
    • 軽量。オープン、安全

ランチ devops

  • best way

    • 組織の文化にする
  • boss に聞く

    • 成功するためにどうすればいいと思う?
  • レガシーなアプリと新しいアプリでは devops のありようが異なる

    • 共通で利用できるツールを探すのがよいだろう

hashicorp

  • vault 推し

  • hachicorp はなぜツールを作るのか

    • デプロイにまつわるサイクルを短くしたい
    • 特定の課題を解決するためのツールを作成している
  • vagrant が一番 star されてる

    • 10000 star
  • ms support

    • 全てのプロダクトで ms をサポートしている
  • enterprise version がある

  • terraform

    • コードでデータセンターを作る
    • demo
    • packer の話
      • package する
        • sh ???
      • image が作成できる
      • packer で作った package は可搬性が高い
    • packer でつくった image から terraform をつかう
      • packer は json で記述
    • tfstate はパフォーマンスのためにあえて使ってる
      • api が遅いから
      • ローカルマシンのための設計
  • terraform enterprise

    • チームで使うための terraform
    • github や atlas をトリガーとして、terraform enterprise 上の UI から apply できる
    • resource dependency graph
    • modules
    • collaboration
      • ゴール
      • インフラを進化するアプリケーションとして扱いたい
        • propose
        • validate in plan
        • approve
        • audit
    • rollback
      • すげぇ
      • terraform enterprise 上の revert できる
        • あとから問題箇所を精査してプルリクすればいいじゃん
    • まるで github のような
    • github integration
    • notification
    • remote state storage
    • remote plan + applies + and locks

mesosphere

  • container の大規模管理
    • SAP の中の人
    • chef の中の人
  • コンテナで複雑化した

  • DC/OS

    • data center を一つのアプリケーションとして考える
      • resource pool
        • CPU
        • NW
        • strage...
    • microservice(in container) = function
    • 全てのバックエンドプラットフォームで対応可能
      • azure container service でも OK
      • ECS でも OK っぽい
    • DC/OS の layer
      • container orchestration
      • job scheduling
      • scale
    • Auto Desk 社の事例
      • AWS Resource 66% cut
      • cost improvements up to 57%
      • ダウンタイムなしに 40 sec でデプロイ
      • 100% uptime
    • dcos cli
      • データセンター全体にミドルウェアをインストール、アプリケーションをデプロイすることができる
        • 構成情報は JSON
      • json でアプリケーションが使うことができるリソースを定義することができる
      • healthcheck
      • label
      • port
    • dcos dashboard
      • 稼働中のアプリケーションの状況を監視できる
      • application の scale の数を簡単に変更できる
    • おまえら DC/OS のブログ書けよw

chef

  • devops へのアプローチ
  • infrastructure as code はなぜ必要か
  • エンジニアの 7割は remote
  • 会社は色々とあるが、共通でやりたいことがあるはずだ
  • インフラとアプリケーションを同じように扱うべきだ
  • 速いのはいいこと、ただしうまくいかなければ意味がない
  • ダイナミックなインフラがなければスピーディーなビジネスはない
  • 継続的に安全に実験する
  • クラウドによって自動化が可能となり、自動化は反復をもたらす
  • CI CD TEST なんでもやろう
  • ミスの責任が単一にあるとミスを起こさないようにするために遅くなる
  • 早く破綻させて破壊しろ
    • みんなで解決してみんなで理解できる
    • なにが間違っていたかを考える
  • 楽しい仕事には人がやってくる

  • devops の分析

    • 利益、生産性、デプロイ回数の向上
  • chef だけでなく、ワークフローが必要

    • chef delivery というのがあるらしい
  • devops も問題点

    • 監査が大変
      • 監査も devops に巻き込む
    • コンプライアンスはテストできる = 統制
    • chef compliance
  • azure native な chef-client がある

  • どっちかというと windows のロードマップに追従している

    • かなり重視しているとのこと
  • inspect

  • 事例

    • デプロイのコスト削減
    • ビルド時間の削減
    • セキュリティを先に、その次に devops というケース
  • chef component

    • opensource と課金コンテンツあり
  • chef server のはなし

    • recipe は step のシーケンス
    • recipe に書き方
  • chef の TDD = TDI

    • 欠陥を早く見つけよう
    • rubocop
      • ruby static code analyzer
      • code standard を当てはめる
    • foodcritic
      • chef のコードスタイルガイドライン
      • ruby のベストプラクティスではない
      • 言語の可能性をあえて制限する
    • chefspec
      • syntax,concepts check unit test
    • test kitchen
      • create realistic server test emvorpm,emt
      • 現実味のあるテスト環境を作る
    • inspec
      • ?
    • chef-compliance
      • serverspec っぽい
  • dsc_script リソース

de:code 2016 5/24 メモ

会社のお金で de:code 2016 に参加させてもらいました。 とにかく Azure と DevOps 推しでした。 以下、なぐりがきメモです。

Active Directory 最新動向

Azure AD

  • Azure AD
  • 13 億の認証 transaction / day
  • ms が内部でも利用している (yammerも)
  • マルチデバイスサポート

ID 同期

  • Azure AD Connect
    • DirSync サポート廃止
    • 自動アップグレード可能
    • 同期間隔の変更
    • ステージングモード
      • 同期サーバのスタンバイを構築可能
      • stanby はエクスポート不可
      • 昇格可能(failover)
    • AD DS と Azure AD の同期が双方向
      • 365 グループをオンプレに持ってくることもできる
    • マルチフォレスト対応
      • ただし複数の同期サーバは構築不可なので、シングルで構築せざるを得ない
      • 同一ユーザの同期はサポートされない
        • 別々の独立したフォレストに同一ユーザがいるようなケース
    • シングルフォレスト
      • シンプル
      • 基本シングルである方が取り回ししやすい
    • マルチフォレスト
      • ID管理、属性管理に気を使うべき
      • 名寄せしないとアカンケースもあるかもしれない
      • 機能的な制約があることが多い
  • Azure AD Connect Health
    • オンプレの監視
    • ADFS + WAP
  • MIM

    • 複数システム間の ID 同期
    • sharepoint ベースの ID 管理
    • 特権管理
    • 証明書
  • 認証

    • 認証エンドポイント
      • MS アカウントと Azure アカウントを単一の ID として扱うアプリが作れる
  • AAD Join - Windows 10

    • ドメイン参加に Azure AD に参加ボタンがある
    • デバイス情報も Azure AD で一元管理すればいいじゃん
  • MS Passport

  • Office 365 先進認証

  • windows 2016 の ADFS

    • openid connect / oatuth 2.0 対応
    • LDAP を認証ストアとしてサポート

アプリケーション

  • IDaaS
  • AzureAD のほうが認証プロトコルが多い
    • WS2016 から同等になる
  • kerberos は Azure AD は非サポート
    • proxyさせればいいらしい
  • クレーム認証のアプリケーション
    • さまざまな開発言語に対応
  • 独自認証
    • 独自認証はクレーム認証に移行するといいのでは
    • フォーム認証を Azure AD にさせることもできるらしい
    • デバイスの制約あり
  • Azure AD には各サービスのログイン情報を保持できる
    • lastpass みたいな

kerberos 認証

AD application proxy

  • Application proxy connector server にアプリケーションがアクセスして Azure AD にプロキシする
    • アクセスパネル -> azure 上の sharepoint で認証 -> proxy -> オンプレに同期 -> オンプレの sharepoint に SSO

Azure domain service

  • azure ad は GPO がないが、それを azure 上で提供できるようにする
    • ntlm / ldap / kerberos / domain join
    • linux サポート

同期フロー

  • オンプレから Azure AD に同期
  • Azure AD から Azure AD Service に同期
  • Azure AD と Azure AD Service はまったく別物
  • 信頼関係を結べない

制約

  • Domain Admins が使えない
  • read only
  • スキーマ変更NG
  • カスタム GPO NG
  • 規定の GPO しか使えない

AzureAD collaboration

  • 組織間
  • B2B

    • 承認フローを通して外部の ID を自社の AD に組み込むことができる
    • しかも外部の ID 認証は、外部の AD で行う
      • ???
      • Azure AD 上で信頼関係を作成しておくことが前提
      • ただし、テナント間の信頼関係ではなく、テナントと個人の信頼関係
  • 組織外

    • Azure AD B2C
    • ソーシャルアカウントに対応 (FB / Twitter)
      • レアルのファンサイトがこれで実装されている
      • サインインにあたり、Azure AD に登録される

セキュリティ

  • AD Identity protection
    • リスクベースの学習機能を提供
  • 特権管理
    • MIM
      • JIT による特権管理
    • kerberos の拡張
    • 期間限定での認証
  • ATA
    • NW IDS

まとめ


Azure SQL Database

ユースケース

  • クラウドを前提とした SaaS
  • 業務アプリ
  • 細かい監視とかフェイルオーバーとかは IaaS で SQL サーバ作ってちょ
  • 厳密なコントロールとかできましぇん
  • SQL Database と SQL Server のコードベースは同じ
  • 今までは SQL Server => SQL Database というコードの流れだったが、2016 から逆になった
  • .NET / PHP / Java / ODBC
  • ruby / python / Node

概説

  • 学習
    • 稼働履歴からのパフォーマンスチューニングのアドバイスがある
      • index
        • 自動インデックス作成
        • 手動インデックス作成
      • query store
        • 稼働状況を記録
        • SQL Server 2016 と同じ機能
        • 性能が劣化したクエリを特定
        • リソースを消費しているクエリを特定
    • 管理ポータルでのリアルタイム監視
    • Threat Detection
      • 異常なDBアクティビティを検出
        • ポリシー作成
        • alert
        • audit log
  • 拡張
    • basic / standard / premium
    • DTU
      • Database Transaction Unit
      • 相対的なデータベース性能
      • 一般的な一連の操作(OLTP)を実行し、1秒間の性能
      • 100 DTU なら 100TPS ?
      • pay for performance
  • インメモリデータベース
  • elastic database モデル
    • 複数のデータベースをまとめる
    • eDTU という単位がある
    • eDTU の範囲内でオートスケール
    • elastic tool
      • job
      • query
      • transaction
      • 複数の DB を管理できる
  • データの安全性
    • MS Managed
    • Always Encrypt オプションあり
      • クライアント側でデータを暗号化
      • カラム単位
      • 暗号化テキストの検索になるので、完全一致のみサポート
    • 行レベルセキュリティ
    • Azure AD 認証をサポート
    • 動的データマスク
      • 重要なデータをマスクして保護
      • マスクしない特権ユーザを設定可能
  • データの保護
    • レプリカを保持
    • SLA 99.99
  • primary + standby *2
  • Active Geo Replication
    • 最大読み取り可能 DB 4 台

Azure と windows と インフラエンジニアと devops

  • devops に定義はない

インフラエンジニアの役割

  • 手法としては
    • infrastructure as code
    • CI
    • 自動テスト
    • 継続的デリバリ
  • なぜ devops
    • 日々変化するマーケットのニーズに対応する
    • 試行錯誤して改善する
  • リリースのフィードバックが大事
    • フィードバックは ops がするといいね
    • azure なら application insight
  • ops は dev とコミュニケーションして business をうまくまわるようにしましょう
  • ドッグフーディング環境
  • A/B テスト
  • よいフィードバック
  • platform の品質向上
  • マイクロサービスアーキテクチャ
    • 小さく作ってこまめにリリース
    • 機能追加やコード修正の影響範囲を最小化
    • リリース時のテストを少なく & 自動的に
  • フィードバックのセルフサービス化
    • たとえば application insights & power bi
    • まぁ、Excelでもいいじゃん
  • インフラエンジニアは最後の砦
    • システム止まると怒られるのは自分なんだけど・・・

理想と現実

  • no risk = no value
  • high value = hi risk
    • high value を目指さないと意味がない
    • high value = low risk を目指しましょう

ギャップを埋めるテクノロジー

  • Windows Server2016
    • devops を意識しまくり
      • container
        • 迅速なデプロイ
        • 柔軟な変更と rollback
        • リソースの有効活用
          • docker command
          • docker first で powershell を開発している
          • docker command を覚えてちょ
            • container 内でアプリケーションのテスト -> ビルド
            • 動くコンテナをリポジトリにおく
            • 展開する
            • 動かなきゃ戻す
          • windows server container
            • 処理やプロセスは OS に共存する
          • hyper-v container
            • 処理やプロセスはコンテナに独立する
          • windows server container と hyper-v container はいつでも切り替えられる
      • nano server
        • 超軽量インストールオプション
        • 数100MBのサーバOSとして登場予定
      • service fabric
        • アプリケーションクラスタ(ノード)管理
        • 空きリソースでアプリケーションを動かす
        • linux 版も出る
      • 特権アクセス管理
      • 高速化へのアプローチ
  • Azure
    • azure resouce manager
      • infrastructure as code
    • azure stack

devops の具体的な実現手法

  • devopsとは人・プロセス・プロダクトの集合体で継続的にエンドユーザに価値を提供することである
  • devops を導入して 10 deploy / day
  • infrastructure as code で手作業なくして障害をなくそう
  • immutable それは破壊的なインフラ

    • 壊れたら捨てればいいじゃない
  • 本番は学びの場

  • だからこそ適切なフィードバックが必要
  • 継続的な実験と学び

  • infrastructure as code

  • devops は plactice から考えて適用するのがよさそう

  • devops をやるなら dev + ops + えらいひとを集めて話す必要がある
  • devops は agile が前提になっている

    • agile を取り入れるには西洋文化を取り入れる
  • 日本人は生産性が低い

    • 他国とは物量が違う
      • 同じことをやるにも日本じゃ大変
      • やっていることが過剰なのでは?
      • be lazy
        • 無駄なことをしない
      • エッセンシャル思考
        • より少なく、しかしより良く
        • やることを計画的に減らす
      • 世の中のほとんどのことはノイズである
      • ask for help
        • 超気軽に質問する
        • ggrks ??? なにそれおいしいの???
        • 超気軽に断ることも大事
      • チーム / PO / UCD が協力してリードタイムを減らす
  • TDD

    • 失敗するテストを書く
    • コードを動くようにする
    • 重複をなくす(refactor)
  • デプロイを8.5ヶ月から1weekに短縮

    • docker + compose + terraform + serf + azure という例

日本向け devops 導入ステップ

  • value stream mapping
    • デプロイまでの流れを可視化する
    • リードタイムとかをいちいち書き込む
      • 無駄を可視化する
  • 文化とギャップ要素のインストール
  • ハックフェスト
    • プレゼンではなくハッカソンする
    • ペアプロする
  • monitarinng と継続的改善

    • 定期的にリードタイム等の改善状況を共有する
  • MS も Rails と思想は似ている

    • レールに載ってれば快適
    • 魔改造はやめよう

フィードバックの質を上げるために

  • A/B テスト

    • 特定のユーザ
      • どうやるんだろ
    • feature flag
      • ボタン一つでアプリケーションを切り替えられる
  • fault injection

    • 本番で障害を発生させる
    • chaos monkey
    • 障害時に正常に動作するか
  • 10 deploy / day できるようになるために devops しよう

最後にその場でブログをアップして終わり http://simplearchitect.hatenablog.com/entry/2016/05/24/185431

boto3 で S3 オブジェクトのコピー

boto3 で S3 の操作メモ

バケットに接続

import boto3

s3 = boto3.resource('s3')
bucket_name = "my-bucket"

bucket = s3.Bucket(bucket_name)

prefix の文字列で bucket 内のオブジェクトをフィルタ

prefix = 'myfolder/original.txt'
bucket.objects.filter(Prefix=prefix)

# => s3.ObjectSummary(bucket_name='my-bucket', key=u'myfolder/original.txt')

同一バケット内でオブジェクトのコピー

"""
CopySource は Dict 型で渡す
"""
s3.Object(bucket_name, new_file).copy_from(CopySource={'Bucket': bucket_name, 'Key': original_file_name})

オブジェクトの削除

s3.Object(bucket_name, original_file_name).delete()

フィルタしたオブジェクトを別フォルダにコピーして削除

試していませんが、別のバケットへのコピーでも動きそうです。

import boto3
import time

s3 = boto3.resource('s3')
bucket_name = 'my-bucket'
bucket = s3.Bucket(bucket_name)

new_folder = "new"
old_folder = "old"

for obj in bucket.objects.filter(Prefix=old_folder):
    old_file = obj.key
    object_name = obj.key.split("/")[-1]
    new_file = '%s/%s' % (new_folder, object_name[-1])
    # コピーが成功するまで5回繰り返す
    for i in xrange(1,6):
      res = s3.Object(bucket.name, new_file).copy_from(CopySource={'Bucket': bucket.name, 'Key': old_file})
      if res['ResponseMetadata']['HTTPStatusCode'] == 200:
          break
      else:
          time.sleep(i)
    # 削除が成功するまで5回繰り返す
    for i in xrange(1,6):
      res = obj.delete()
      if res['ResponseMetadata']['HTTPStatusCode'] == 204:
          print "moved %s complete" % new_file
          break
      else:
          time.sleep(i)

powershell の連想配列を JSON に変換する

ハッシュを作成します。 @{"Key" = "Value"; } の形式です。

$Members = @{
  "id" = 1;
  "Name" = "hoge";
}

PSObject を生成します

$MessageObject = New-Object -TypeName PSObject

PSObject にメンバーを追加します

foreach ($key in $Members.Keys) {
    Add-Member -InputObject $MessageObject -MemberType NoteProperty -Name $key -Value $Members[$key]
}

JSON にコンバートします

$MessageJson = ConvertTo-Json -Compress $MessageObject

みてみます。

> $MessageJson
{"id":1,"Name":"hoge"}

簡単ですね!

PowerShell再入門:11. PSObjectとは | $m0t0k1x2["code"].content
PowerShell で JSON をファイル入出力 する - tech.guitarrapc.cóm
PowerShell連想配列(ハッシュ) CapmNetwork

はじめての AWS Lambda python で boto3 から ec2 を起動する

はじめての AWS Lambda で boto3 から ec2 を起動する

いまさら感ありありですが表題のことを Management Console からやってみます。

初期画面

Screen Shot 2016-03-03 at 10.43.42.png

bluprint

Get Started で進むとたくさんのサンプルから選ぶことができますが、今回は Skip します

Screen Shot 2016-03-03 at 10.43.54.png

Configure function

設定画面が表示されますので、さっそく Lambda Function を定義していきます。

Screen Shot 2016-03-03 at 10.44.10.png

  • Name
    • Lambda Function の名前。
  • Description
    • 説明を記載します。必須ではありません。
  • Runtime
    • 執筆当時は以下のランタイムがありました。

今回は python2.7 にします。 (というか java も node.js もさっぱりです。。)

Lambda function code

デプロイ方法は 3 種類あります。

  • Edit Code inline
    • 画面のエディタに直接記述
  • Upload a .ZIP file
    • zip ファイルを upload
    • cli からやるときは zip でやるとよさそうです
  • Upload a .ZIP from Amazon S3
    • S3 にコードをアップロードしておき、その S3 URL を記載します

今回は Edit Code inline でやってみます。
test タグが Truestoppedインスタンスを起動するという単純なスクリプトを用意しました。

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import sys
import boto3

ec2 = boto3.resource('ec2')


def get_specified_tagged_instance_ids(target_tag):
    """
    get target tagged instance-id
    """
    try:
        instances = ec2.instances.filter(
            Filters=[
                {'Name': 'tag:%s' % target_tag, 'Values': ['True']},
                {'Name': 'instance-state-name', 'Values': ['stopped']}])
    except Exception, e:
        print(e)
        sys.exit(2)

    if not instances is None:
        i = []
        for instance in instances:
            i.append(instance.instance_id)
    else:
        print("not found target tagged instances")
        sys.exit(0)

    return i


def start_instances(target_tag):
    """
    start instances
    """
    try:
        instances = get_specified_tagged_instance_ids(target_tag)
    except Exception, e:
        print(e)
        sys.exit(2)

    for instance in instances:
        res = ec2.instances.filter(InstanceIds=[instance]).start()
        status_code = res[0]["ResponseMetadata"]["HTTPStatusCode"]
        if status_code == 200:
            print("operation complete. target -> %s" % instance)
        else:
            print("operation failed. target -> %s" % instance)
            sys.exit(1)


def lambda_handler(event, context):
    target_tag = "test"
    start_instances(target_tag)
    sys.exit(0)

lambda_hanlder()__main__ 的に使うようにしてみました。 なお、lambda_hanlder() という名前は好きなものに変えることができます。

Lambda function handler and role

  • Handler
    • デフォルトは lambda_function.lambda_handler
    • 例えば test.py の hello_world() を実行したい場合は test.hello_world とすることができます
  • Role
    • 適切な IAM Role を付与します。

Role について、今回は basic vpc から作成してみます。 デフォルトの policy は以下のようなものでした。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:*:*:*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:CreateNetworkInterface",
        "ec2:DescribeNetworkInterfaces",
        "ec2:DetachNetworkInterface",
        "ec2:DeleteNetworkInterface"
      ],
      "Resource": "*"
    }
  ]
}

ここに ec2:DescribeInstancesec2:StartInstances を追加して保存します。

Advanced settings

  • Memory
    • 128MB から 1536MB まで選択できます
  • Timeout
    • 5min まで設定できます
  • VPC
    • VPC を選択すると、lambda が起動する Subnet / Secrurity Groupを指定できます

確認画面

こんな感じになりました。 Create function に進みます。

Screen Shot 2016-03-03 at 11.31.42.png

Function の定義

Screen Shot 2016-03-03 at 11.33.43.png

今回は一日一回実行することにしますので Event Source のみ使います。

Screen Shot 2016-03-03 at 11.58.01.png

Add event source から CloudWatch Events Schedule を選択します。

Screen Shot 2016-03-03 at 11.59.30.png

  • Rule Name
    • 名前をつけます
  • Rule Description
    • 説明を記載します
  • Schedule Expression
    • rate (*) は繰り返し実行する時に使います
    • cron も書けますのでとても便利です
      • cron の時間は UTC のみです

指定したら submit します。Enable now の場合、少し待つと lambda が起動します。 Monitoring タブと CloudWatch Logs で稼働状況を確認できます。

CloudWatch Logs

Monitoring タブの View logs in CloudWatch からこの function の log stream に移動できます。
print 文の内容が表示されていますね。

Screen Shot 2016-03-03 at 12.22.02.png

awscli

一連の流れを awscli で行うとしたら以下の様な感じかと。

  • コードを zip にする
  • iam role を作成しておく(手抜き)
  • function を作成する
    • zip ファイルなので file:// ではなく、 fileb:// なことに注意
aws lambda create-function \
  --function-name auto_start_test \
  --runtime python2.7 \
  --role arn:aws:iam::**********:role/lambda_basic_vpc_execution \
  --handler auto_start.lambda_handler \
  --zip-file fileb://auto_start.zip \
  --timeout 30 \
  --memory-size 128 \
  --vpc-config SubnetIds=subnet-*******,SecurityGroupIds=sg-****** \
  --region ap-northeast-1
  • event を作成する
aws --profile lk-staging events put-rule \
  --name test \
  --schedule-expression "rate(5 minutes)" \
  --state ENABLED

{
    "RuleArn": "arn:aws:events:ap-northeast-1:**********:rule/test"
}

ただ、function と event の関連付ける方法がわかりませんでした。。。
ご存知の方、いらっしゃれば教えて下さい!

CentOS7 on vagrant に docker をインストールして nginx で hello world するまで

CentOS7 (vagrant) に docker をインストールして nginx で hello world するまでの記録です。 CentOS7 が vagrant up されていることが前提です。

docker インストール

公式 にあったワンライナーでインストール後、起動します。
なお、このワンライナー/etc/yum.repos.d/docker.repo を自動で作成してくれます。

$ curl -fsSL https://get.docker.com/ | sh
$ systemctl start docker.service

↓ インストール中のログ

[vagrant@localhost ~]$ curl -fsSL https://get.docker.com/ | sh
+ sudo -E sh -c 'sleep 3; yum -y -q install docker-engine'
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
warning: /var/cache/yum/x86_64/7/docker-main-repo/packages/docker-engine-selinux-1.10.0-1.el7.centos.noarch.rpm: Header V4 RSA/SHA512 Signature, key ID 2c52609d: NOKEY
docker-engine-selinux-1.10.0-1.el7.centos.noarch.rpm の公開鍵がインストールされていません
Importing GPG key 0x2C52609D:
 Userid     : "Docker Release Tool (releasedocker) <docker@docker.com>"
 Fingerprint: 5811 8e89 f3a9 1289 7c07 0adb f762 2157 2c52 609d
 From       : https://yum.dockerproject.org/gpg
Created symlink from /etc/systemd/system/sysinit.target.wants/lvm2-lvmpolld.socket to /usr/lib/systemd/system/lvm2-lvmpolld.socket.

If you would like to use Docker as a non-root user, you should now consider
adding your user to the "docker" group with something like:

  sudo usermod -aG docker vagrant

Remember that you will have to log out and back in for this to take effect!

非 root ユーザで docker コマンドを使うにはコマンドを叩くように言われているので、ついでに実行しておきます。

$ sudo usermod -aG docker vagrant

docker のバージョンは以下のようになりました。

[vagrant@localhost docker]$ docker version
Client:
 Version:      1.10.0
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   590d5108
 Built:        Thu Feb  4 18:34:50 2016
 OS/Arch:      linux/amd64
Cannot connect to the Docker daemon. Is the docker daemon running on this host?

Dockerfile の作成

こちらを参考にしながら、適当なディレクトリを作り、Dockerfile を作成します。

[vagrant@localhost docker]$ tree
.
├── Dockerfile
└── index.html

0 directories, 2 files

Dockerfile の中身はこんな感じです。

FROM centos
MAINTAINER hoge hoge@hoge.hoge
RUN yum install -y epel-release
RUN yum install -y nginx
ADD index.html /usr/share/nginx/html/

EXPOSE 80
ENTRYPOINT ["/usr/sbin/nginx", "-g", "daemon off;", "-c", "/etc/nginx/nginx.conf"]

GPGキーでWARNING出ましたが、ここでは一旦無視。

  • FROM はイメージ名。ローカルになければ dockerhub から取ってくる
  • MAINTAINER はメンテナの名前とメールアドレスを記入
  • RUN はイメージ起動後に実行するコマンド
  • ADD はファイルを指定したパスに配置
  • EXPOSE は Listen するポート
  • ENTRYPOINT は docker run 時に実行するコマンド

index.html には hello world とだけ書いておきました。

docker build

build します。

$ sudo docker build -t centos/nginx:1.0 .
  • -t は image にタグを打つオプション
    • centos/nginx は REPOSITORY 名
    • :1.0 は TAG 名
  • 最後の引数に Dockerfile のあるディレクトリを指定

build が成功すると image ができあがります。

[vagrant@localhost docker]$ sudo docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
centos/nginx        1.1                 80d766bb9338        About an hour ago   356 MB
centos/nginx        1.0                 d1345ae2d9a6        9 hours ago         356 MB
centos              latest              61b442687d68        6 weeks ago         196.6 MB
hello-world         latest              690ed74de00f        3 months ago        960 B

docker 実行

build したイメージを実行します。

$ sudo docker run -d -p 80:80 centos/nginx:1.1
753d92d2bf360a529e881efaee564f86840e8d2d649f20825a7132093b45683e
  • -d は docker をバックグラウンド実行
  • -p はポートフォワード設定。 ローカル側:docker側 の順番
  • 実行後の標準出力はコンテナID
 sudo docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                NAMES
753d92d2bf36        centos/nginx:1.1    "/usr/sbin/nginx -g '"   3 minutes ago       Up 3 minutes        0.0.0.0:80->80/tcp   determined_tesla

コンテナの停止、削除はこのコンテナIDを利用します。

コンテナの中に入ってシェル操作するには以下のオプションで docker run します。

$ sudo docker run -it --entrypoint "/bin/bash" centos/nginx:1.2
[root@920ea5c72a47 /]# 
  • --entrypoint を指定することで Dockerfile の ENTRYPOINT を上書き

確認

これで nginx が起動したので、index.html が見えるはずです。

$ curl -s localhost
hello world

見えました。
ブラウザから確認する場合は vagrant の ip アドレスを指定するとよいでしょう。

Screenshot-3.png

コンテナの停止・削除

コンテナを停止するには以下のコマンドを実行します。

$ sudo docker stop *コンテナID*

コンテナを削除するには以下のコマンドを実行します。

$ sudo docker rm *コンテナID*

コンテナが増えると停止がめんどうなので、for 文でぐるぐるしたり。

$ for p in $(sudo docker ps -a -q); do sudo docker rm -f ${p}; done

image の削除

image の削除は以下のコマンドを実行します。

$ sudo docker rmi *イメージID*

コンテナ実行中は削除できないので注意。

以上、ここまでdesu。

参考

参考にさせていただきましたm(__)m

https://docs.docker.com/engine/installation/linux/centos/ http://www.atmarkit.co.jp/ait/articles/1407/08/news031.html http://qiita.com/hihihiroro/items/d7ceaadc9340a4dbeb8f http://heartbeats.jp/hbblog/2014/07/3-tips-for-nginx-on-docker.html http://qiita.com/kasaharu/items/d4654193d75c67d65226 http://qiita.com/hnakamur/items/afddaa3dbe48ad2b8b5c

apache で X-Forwarded-For をログに記録する

記事としてよくありますが、ちょっとハマったので記録として。

<VirtualHost *:80>
    ServerName hoge.com
    DocumentRoot "/var/www/html"
    LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined_x
    CustomLog "/var/log/httpd/access_hoge.com.log" combined_x
    ErrorLog  "/var/log/httpd/error_hoge.com.log"
</VirtualHost>

ELB 配下で使っているため、 %h は除去しました。
また、 combind_x としているのは /etc/httpd/httpd.conf にある LogFormat のデフォルト設定に上書きされてしまうことを回避するためです。

 218 #
 219 # Load config files from the config directory "/etc/httpd/conf.d".
 220 #
 221 Include conf.d/*.conf

 493 #
 494 # The following directives define some format nicknames for use with
 495 # a CustomLog directive (see below).
 496 #
 497 LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

ログは以下のようになります。

52.68.214.11 - - [10/Feb/2016:15:58:36 +0900] "GET /index.html HTTP/1.1" 200 47 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.103 Safari/537.36"

以上です。