Jenkinsオジサンからの卒業その3(Drone.ioを試してみた)
Drone.io
Continuous Integration · drone.io
GitHub以外のVCSホスティングサイトとの連携もでき、OSSなのでオンプレ環境でも利用可能。細かい機能面は今後に期待、か。以下は、OSS版ではなく https://drone.io/ で試したもの。
使い方
- アカウントの作成は、GitHub連携・BitBucket連携・Google連携で可能
- 自動ビルドさせたいリポジトリを選択する
- 標準で対応しているビルド構成でよければ、これだけでビルド実行できる
- 対応していないビルド構成の場合は、ビルド用のコマンドを drone.io の Settings ページで入力する必要がある
- Java デフォルトで対応しているビルドスクリプトは Ant, Maven
- Gradleを使いたい場合は、gradlew を推奨とのこと
- gradlew をリポジトリにcommitしておく必要あり
- ビルドコマンドはこんな感じ
- Gradleを使いたい場合は、gradlew を推奨とのこと
chmod +x gradlew ./gradlew [task]
- リポジトリ内にビルド設定を定義できない??
自動ビルドのトリガー
- Push
- default branch 以外のPushもビルド
- GitHub上のPRと連携してくれない
- ビルドがとおったPR(commit)か?は確認できない
PRと連携できていないのは残念。
ビルド結果
- build badge のURLを提供
- build badge 表示は
latest
(最後に実行したビルド)のみ
- build badge 表示は
- ビルド成果物(Artifacts)の保存
- マスタービルドで生成されるJar/Warを指定しておくと、Downloadが可能
- Mail通知
- ビルド後のデプロイタスクも設定可能
単純なビルドの成否を出力・通知するだけのTravisCIとの大きな違いとして、Artifactsの保存やデプロイタスクがある。branchごとではなく、とにかく最後にビルドした結果が残るという仕様が、少し残念なところ。
その他
- 内部的にはコンテナ上でビルドが走る
- 各ステップの詳細ログが見れる
- UIは良く言えばシンプル、なんか物足りなくも感じる...
SampleでDrone.ioビルドを設定してみたリポジトリはコチラ
https://github.com/shionit/sample-droneio
Jenkinsオジサンからの卒業その2(CircleCIを試してみた)
Circle CI
GitHubとの親和性は高く、手軽に使えていい感じ。
使い方
- Circle CI にGitHubアカウントでログイン
- 自動ビルドさせたいGitHubリポジトリを選択する
- これだけでビルド実行できる
- 対象のリポジトリに
circle.yml
を置かなくてもビルドは可能のようだが、今回試したJavaプロジェクト(TravisCIで試したものと中身は同一)では置かないとビルドが通らなかった- build.gradle ファイルからJDKのバージョンが読み取れなかった、と思われる
- Language Guide: Java - CircleCI
自動ビルドのトリガー
- Push
- default branch 以外のPushもビルド
- Pull Request
- 追加Pushで再ビルド
Travis CIと遜色ない印象。
ビルド結果
- build badge のURLを提供
- ビルド成果物(Artifacts)の保存
- マスタービルドで生成されるJar/Warの他に、単体テストレポートや静的解析ツール実行結果も残しておけるので、閲覧が可能
- Mail通知
- Slack通知
- ビルド後のデプロイタスクも設定可能
単純なビルドの成否を出力・通知するだけのTravisCIとの大きな違いとして、Artifactsの保存やデプロイタスクがある。
その他
- 内部的にはコンテナ(デフォルトではUbuntu)上でビルドが走る
- ビルドの各ステップの処理時間が確認できる
- 各ステップの詳細ログが見れる
- ビルド用コンテナにsshしてビルド失敗原因の調査や細かな環境設定が可能
- テスト実行の並列度など細かな設定が可能
- 複数コンテナで並行実行させるには有償プランにする必要あり
- build スクリプトは自動検出
- TravisCIと同様
SampleでCircleCIビルドを設定してみたリポジトリはコチラ
https://github.com/shionit/sample-circleci
Jenkinsオジサンからの卒業その1(TravisCIを試してみた)
Travis CI
Travis CI - Test and Deploy Your Code with Confidence
GitHubとの親和性は高く、手軽に使えていい感じ。
使い方
自動ビルドのトリガー
- Push
- default branch 以外のPushもビルド
- Pull Request
- 追加Pushで再ビルド
ビルド結果
- build badge のURLを提供
- Mail通知
- Slack通知
- ビルドがSuccessかFailか?の結果を出すシンプルな出力
- Test結果のレポート表示はできない
- ビルド成果物(artifacts)の保存もできない
その他
SampleでTravisCIビルドを設定してみたリポジトリはコチラ
https://github.com/shionit/chronos
自習系GitHubリポジトリをひとつにまとめてみた
厳密には、"今日覚えたこと"を書いていくという、一部で流行りの気配を見せている til (Today I learned) リポジトリの真似をして、自習系リポジトリをまとめてみた、という記事ですな。
(切欠) GithubでTILというリポジトリが流行りつつあるのかもしれない - 生涯未熟
元リポジトリ(4つ)
出来上がり状態
新設した til リポジトリに各リポジトリを内包させる形で git filter-branch
していく。各リポジトリのコミット履歴は残り、元リポジトリの名称のブランチから master にマージされたかたちになる。
参考にしたサイト
コメント欄にあるとおり、本文中の git filter-branch
の部分がMacだとエラーになってしまうので、コメントにあるコマンドを使った。
また、electron-sample リポジトリは、直下に同名のディレクトリが存在していたので、これを src にリネームしたうえで実施してみたが、「コミット履歴中にリポジトリ名と同名のフォルダが存在すると...」というこれまたコメント欄にあるとおりのエラーになったので、こちらもMac版のコマンドに修正したうえで実施した。
つまり、まとめると
#GitHub Account ACCOUNT=shionit #Source Repository REPO=XXXXX # at dest repository path git remote add $REPO git@github.com:$ACCOUNT/$REPO.git git fetch $REPO git checkout -b $REPO $REPO/master git filter-branch -f --tree-filter "mkdir __temp__ && git mv -k {,.[!.],..[!.]}* __temp__/ && mkdir $REPO && git mv -k __temp__/{,.[!.],..[!.]}* $REPO/" git checkout master git merge $REPO
結果、単一の自習リポジトリにまとめられてスッキリですな☆
Mac環境構築の自動化と設定バックアップ
以下の記事を参考に、Home Brew と Brew Cask を使って環境構築の自動化(省力化)をしてみた。
他にも、Ansibleを使ったMac環境構築の記事はありましたが、AnsbileのバージョンUp時の仕様変更についていくのツライ、Brew Bundleがいい感じにメンテされていきそう、mackupもシンプルで素敵☆ということで上記の記事に沿って対応することにしました。
上記の記事では brew brewdle
コマンドを使っていますが、GitHubの本家リポジトリを見る限り brew brewdler
brew bundler
といったコマンドとともに下位互換性を保つためのエイリアス実装となっており、今後は brew bundle
が公式なコマンドとなっていくものと思われるので、これで実装しといた。
GitHub - Homebrew/homebrew-bundle: Bundler for non-Ruby dependencies from Homebrew
他にも参考にした記事、というかbrewで取得するアプリケーションの一覧を覗くだけでも、知らない便利アプリに出会うことができて有意義でした。
Mac の開発環境構築を自動化する (2015 年初旬編) - t-wadaのブログ
既存環境のMac でもansible で環境構築を自動化するには - snowlongの日記
2016/04/21追記
便利な mackup がバージョンアップしてオプション指定方法が変わったのか、パラメータを変えてあげないと動かなくなったのでメモ。
@daily /usr/local/bin/mackup -f backup
2016/07/28追記
Home brew cask の Caskroom のデフォルトロケーションが変更されたこと*1に伴い、crontabの内容を見直す必要ができたのでメモ。
@weekly cd /usr/local/bin/ && time nice -n19 brew update && time nice -n19 brew upgrade && time nice -n19 brew cleanup && for c in `brew cask list`; do ! brew cask info $c | grep -qF "Not installed" || time nice -n19 brew cask install $c; done && time nice -n19 brew cask cleanup && for c in /usr/local/Caskroom/*; do vl=(`ls -t $c`) && for v in "${vl[@]:1}"; do \rm -rf "$c/$v"; done; done; for c in /usr/local/Caskroom/*/.metadata; do vl=(`ls -t $c`) && for v in "${vl[@]:1}"; do \rm -rf "$c/$v"; done; done
dotfilesの整備
また、GitHub に公開されている dotfiles 系リポジトリを参考にシェルまわりの環境設定も合わせて整備した。
GitHub - mathiasbynens/dotfiles: .files, including ~/.macos — sensible hacker defaults for macOS
GitHub - yuku-t/dotfiles: My dotfiles
初期設定まわりが随分とスッキリして、バックアップも取れて安心安心☆というのもありますが、個人的には .gitconfig にgitコマンドのエイリアスを定義しまくって効率化!というのを色々とキャッチアップできたのが大変有用でした。最後に、出来上がったdotfilesはコチラ↓
Dockerのバージョンアップしたらコマンドがエラーになった
Dockerのバージョンアップ(1.9.1->1.10.1)したら、dockerコマンドがエラーを返すようになった。
$ docker ps Error response from daemon: client is newer than server (client API version: 1.22, server API version: 1.21)
サーバーの再起動なり、アップグレードをすることで解消する模様。
$ docker-machine upgrade Waiting for SSH to be available... Detecting the provisioner... Upgrading docker... Stopping machine to do the upgrade... (中略) Restarting docker... $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
直った。良かった。
情報セキュリティの体系化
偉い人からのデッカイボールに対応するためのメモメモ。。
情報セキュリティの目的
- 機密性(Confidentiality)
- アクセス権を持つ者だけが、情報にアクセスできることを確実にすること
- アクセス制御、パスワード認証、暗号化、入退室管理
- アクセス権を持つ者だけが、情報にアクセスできることを確実にすること
- 完全性(Integrity)
- 情報及び処理方法が正確であることおよび完全であることを保護すること
- デジタル署名、メッセージダイジェストによる改竄防止
- 情報及び処理方法が正確であることおよび完全であることを保護すること
- 可用性(Availability)
- 責任追跡生 / 説明可能性(Accountability)
- システムが、いつ、誰に利用されたかを追跡できること
- アクセスログの記録、デジタル署名による否認防止
- システムが、いつ、誰に利用されたかを追跡できること
- 真正性 / 認証性(Authenticity)
- 情報の作成者や送信者が(なりすまし/偽物ではなく)本物であることを保証すること
- デジタル署名、パスワード認証
- 情報の作成者や送信者が(なりすまし/偽物ではなく)本物であることを保証すること
- 信頼性(Reliability)
- システムやプロセスが矛盾なく動作すること、一貫して動作すること
- ネットワークやシステムの2重化による呼称対策、サーバ室での温度管理、負荷監視
- システムやプロセスが矛盾なく動作すること、一貫して動作すること
前半の3つを「セキュリティのCIA」と呼ぶ。最近は、後半の3つを追加して6大要素とすることもある。
セキュリティの機能
- 抑制
- セキュリティの存在が、犯罪・事故などを牽制・抑止する
- ホスティング、外部委託、不要なサービスの停止、監視カメラ、規則・契約書への明記
- セキュリティの存在が、犯罪・事故などを牽制・抑止する
- 予防
- 検知
- 事故・障害・不正などを速やかに発見・通知する
- ログの監視、侵入検知システム、SNMPによるネットワーク管理
- 事故・障害・不正などを速やかに発見・通知する
- 回復
- 事故・障害から正常な状態に回復する
- バックアップ、代替機の確保、復旧対応マニュアルの作成
- 事故・障害から正常な状態に回復する
セキュリティの対策
- 物理的対策
- 建物・設備基準
- 技術的対策
- 技術基準:ツール導入など
- 運用管理対策
- 運用基準:セキュリティポリシー、人、教育など
情報セキュリティの指す範囲
- 情報セキュリティ
- コンピュータ・セキュリティ
- ネットワーク・セキュリティ
- (建物・設備などの)物理セキュリティ
- コンピュータ・セキュリティ
情報セキュリティの技術的対策
- 監査(Audit)
- 他の5階層全体を指し、導入した製品自身に設定ミスがないか、利用者がルールどおりに使用しているかなどを監視し、監査証跡を記録する製品およびサービス
- 暗号化(Encryption)
- 特権定義(Priviledge Definition / Single Sign On)
- 個人の属性に対して定義されたシステムへのアクセス権限を管理運営する認可の製品およびサービス
- 認証(Authentication)
- ネットワークやサーバにアクセスする際の、本人性を確認する製品およびサービス
- 通信規制(Access Control)
- インターネットに接続するする際に必要なファイアウォール製品およびサービス
- データ保護(Data Protection / Data Integrity)
- アンチウィルスに関する製品およびサービス
時系列で見た考え方
- 事前対策
- ファイアウォール、ウィルス対策サーバ、安全なWebアプリ開発、ハードディスク暗号化、サーバ室での安定稼働、パッチ適用
- 発生時の対策
- ネットワークからの切り離し、社内への周知、ホームページ上での公表、政府機関への連絡、HDDやメモリ内の証拠保全作業
- 発生後の対応、見直し
- 発生したインシデントのレビュー、ポリシーの改定や新たな対応策の導入
- 日常の運用
- 社員の教育、ログの監視、定期的バックアップ、脆弱性情報の収集、アカウント登録削除の管理徹底