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
- リソース管理 *コンテナ技術の標準化団体がある
- namespace
- docker が実現したこと
- software が必要な全てをファイルシステムに包む
- どのような環境でも実行を保証
- 軽量。オープン、安全
ランチ devops
best way
- 組織の文化にする
boss に聞く
- 成功するためにどうすればいいと思う?
レガシーなアプリと新しいアプリでは devops のありようが異なる
- 共通で利用できるツールを探すのがよいだろう
hashicorp
vault 推し
- セキュリティのツール
hachicorp はなぜツールを作るのか
- デプロイにまつわるサイクルを短くしたい
- 特定の課題を解決するためのツールを作成している
vagrant が一番 star されてる
- 10000 star
ms support
- 全てのプロダクトで ms をサポートしている
enterprise version がある
terraform
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...
- resource pool
- microservice(in container) = function
- 全てのバックエンドプラットフォームで対応可能
- azure container service でも OK
- ECS でも OK っぽい
- DC/OS の layer
- container orchestration
- job scheduling
- scale
- Auto Desk 社の事例
- dcos cli
- dcos dashboard
- 稼働中のアプリケーションの状況を監視できる
- application の scale の数を簡単に変更できる
- おまえら DC/OS のブログ書けよw
- data center を一つのアプリケーションとして考える
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
dsc_script リソース
- powershell dsc をそのまま書ける
- powershell 5 から
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 サポート廃止
- 自動アップグレード可能
- local SQL Server が稼働
- powershell で管理できる
- 同期間隔の変更
- 3h -> 30 min
- powershell で管理
- ステージングモード
- 同期サーバのスタンバイを構築可能
- 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 先進認証
- office client の AD 認証ライブラリ
windows 2016 の ADFS
アプリケーション
- IDaaS
- AzureAD のほうが認証プロトコルが多い
- WS2016 から同等になる
- kerberos は Azure AD は非サポート
- proxyさせればいいらしい
- クレーム認証のアプリケーション
- さまざまな開発言語に対応
- 独自認証
- 独自認証はクレーム認証に移行するといいのでは
- フォーム認証を Azure AD にさせることもできるらしい
- デバイスの制約あり
- Azure AD には各サービスのログイン情報を保持できる
- lastpass みたいな
kerberos 認証
- windows 統合認証
- ?
AD application proxy
- Application proxy connector server にアプリケーションがアクセスして Azure AD にプロキシする
- アクセスパネル -> azure 上の sharepoint で認証 -> proxy -> オンプレに同期 -> オンプレの sharepoint に SSO
Azure domain service
同期フロー
- オンプレから Azure AD に同期
- Azure AD から Azure AD Service に同期
- Azure AD と Azure AD Service はまったく別物
- 信頼関係を結べない
制約
AzureAD collaboration
- 組織間
-
- 承認フローを通して外部の ID を自社の AD に組み込むことができる
- しかも外部の ID 認証は、外部の AD で行う
- ???
- Azure AD 上で信頼関係を作成しておくことが前提
- ただし、テナント間の信頼関係ではなく、テナントと個人の信頼関係
組織外
- Azure AD B2C
- ソーシャルアカウントに対応 (FB / Twitter)
- レアルのファンサイトがこれで実装されている
- サインインにあたり、Azure AD に登録される
セキュリティ
まとめ
- オンプレ + Azure AD = Active Directory
Azure SQL Database
- SQL Server と SQL Database の違い
- PaaS
ユースケース
- クラウドを前提とした 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 と同じ機能
- 性能が劣化したクエリを特定
- リソースを消費しているクエリを特定
- index
- 管理ポータルでのリアルタイム監視
- Threat Detection
- 異常なDBアクティビティを検出
- ポリシー作成
- alert
- audit log
- 異常なDBアクティビティを検出
- 稼働履歴からのパフォーマンスチューニングのアドバイスがある
- 拡張
- basic / standard / premium
- DTU
- Database Transaction Unit
- 相対的なデータベース性能
- 一般的な一連の操作(OLTP)を実行し、1秒間の性能
- 100 DTU なら 100TPS ?
- pay for performance
- インメモリデータベース
- elastic database モデル
- データの安全性
- MS Managed
- Always Encrypt オプションあり
- クライアント側でデータを暗号化
- カラム単位
- 暗号化テキストの検索になるので、完全一致のみサポート
- 行レベルセキュリティ
- Azure AD 認証をサポート
- 動的データマスク
- 重要なデータをマスクして保護
- マスクしない特権ユーザを設定可能
- データの保護
- レプリカを保持
- SLA 99.99
- primary + standby *2
- 同期レプリケーション
- 常に 3 台構成
- 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
- リソースの有効活用
- nano server
- 超軽量インストールオプション
- 数100MBのサーバOSとして登場予定
- service fabric
- 特権アクセス管理
- 高速化へのアプローチ
- CPU ボトルネックの世界が来てる
- container
- devops を意識しまくり
- Azure
- azure resouce manager
- infrastructure as code
- azure stack
- azure resouce manager
devops の具体的な実現手法
- devopsとは人・プロセス・プロダクトの集合体で継続的にエンドユーザに価値を提供することである
- devops を導入して 10 deploy / day
- infrastructure as code で手作業なくして障害をなくそう
immutable それは破壊的なインフラ
- 壊れたら捨てればいいじゃない
本番は学びの場
- だからこそ適切なフィードバックが必要
継続的な実験と学び
infrastructure as code
- visual studio から docker コンテナデプロイ
- visual studio から仮想マシン起動
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 からやってみます。
初期画面
bluprint
Get Started
で進むとたくさんのサンプルから選ぶことができますが、今回は Skip
します
Configure function
設定画面が表示されますので、さっそく Lambda Function を定義していきます。
- 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
タグが True
で stopped
なインスタンスを起動するという単純なスクリプトを用意しました。
#!/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:DescribeInstances
と ec2:StartInstances
を追加して保存します。
Advanced settings
- Memory
- 128MB から 1536MB まで選択できます
- Timeout
- 5min まで設定できます
- VPC
- VPC を選択すると、lambda が起動する Subnet / Secrurity Groupを指定できます
確認画面
こんな感じになりました。 Create function に進みます。
Function の定義
今回は一日一回実行することにしますので Event Source のみ使います。
Add event source から CloudWatch Events Schedule を選択します。
- 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 文の内容が表示されていますね。
awscli
一連の流れを awscli で行うとしたら以下の様な感じかと。
- コードを zip にする
- iam role を作成しておく(手抜き)
- function を作成する
- zip ファイルなので
file://
ではなく、fileb://
なことに注意
- zip ファイルなので
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 を上書き
起動中のコンテナに入るには以下のようにします。
$ sudo docker exec -i -t *コンテナID* /bin/bash
確認
これで nginx が起動したので、index.html が見えるはずです。
$ curl -s localhost hello world
見えました。
ブラウザから確認する場合は vagrant の ip アドレスを指定するとよいでしょう。
コンテナの停止・削除
コンテナを停止するには以下のコマンドを実行します。
$ 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"
以上です。