はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

概要 いつの間にか cloudstack builder が support されていたので IDCFクラウドに仮想マシンテンプレートを作成。 環境 Packer v1.0.0 IDCFクラウド側の事前準備 エンドポイント URL, API_KEY, SECRET_KEY 取得 ソースのパブリック IP アドレス ID を取得※ Keypair 登録 ※packer にて temporary で public IP address を取得可能ですが、IDCFクラウドにおいては以下のエラーが出るため、デフォルトでついてくるソース IP アドレスを利用 { "variables": { "api_url": "https://compute.jp-east.idcfcloud.com/client/api", "api_key": "YOUR_API_KEY", "secret_key": "

はじめに 今回は以下のクラウドサーバーを対象にIOPSを計測し、ストレージの性能を比較します。IDCFクラウドについては初期のゾーンであるhenryと最新ゾーンのluxの2種類を計測し、ゾーン間の違いも計測してみます。 ＊2017/06/05：NIFTYクラウドの結果を追加しました。 計測対象： Amazon Web Services (AWS) (ボリュームタイプ：gp2/SSD) Google Cloud Platform (GCP) (SSD) IDCFクラウド（ゾーン：lux/SSD） IDCFクラウド（ゾーン：henry/HDD） NIFTY Cloud（ゾーン：east-11） NIFTY Cloud（ゾーン：east-14） 1. 前提知識 ディスクの性能がなぜ大事？IOPSとは？ （自明な方は読み飛ばして下さい） 1.1 仮想化環境とストレージ性能 仮想化環境ではストレージ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

前提 GoogleCloudPlatform のアカウントは取得済み Google Cloud SDK インストールおよび認証済み terraformはインストール済み（今回の環境では0.6.8） 事前作業 GoogleDevelopersConsole にて以下の作業を行っておく プロジェクトの作成 OAuth の同意設定 サービスアカウントキーの取得（JSON形式） 手順 tfファイルと同じ場所に事前に取得したサービスアカウントキーのJSONを置く ■tfファイルを作成 variable "project" {} variable "region" { default = "asia-east1" } variable "cluster_name" {} variable "zone" {} variable "network" {} variable "initial_node_co

概要 障害対応 = 昔からよくあるアラート検知したらとりあえずプロセス再起動的なやつ。 CloudWatch アラームの SNS メッセージを Lambda で受け取って、対象インスタンスに対して EC2 Run Command (SSM) で定義されたコマンドを実行する。 EC2 セットアップ 1. IAM Role 作成 EC2 に紐付ける Role に以下の Policy をアタッチして作成する。 AmazonSSMFullAccess 2. EC2 インスタンス作成 上記で作成した IAM Role を付与してインスタンス作成。 OS は以下で構築。 Amazon Linux AMI 2016.09.1 (HVM) 3. SSM エージェントインストール 起動したインスタンスで以下コマンドでインストール。

概要 drone0.4 の terraform plugin で インフラCI する レポジトリは Github のプライベートレポジトリを作成 デプロイ先は AWS drone 0.4 の環境構築に関しては以前の記事参照 terraform plugin の詳細はこちら 前提 drone の OAuth applications 登録済み terraform の tfstate は S3 で管理する 準備 レポジトリの作成 Github 上で CI 用の新規レポジトリを作成する レポジトリを Activate する Drone にアクセスして、作成したレポジトリを選択して Activate する Deploy Key は自動で登録されるため、Github, Drone の設定についてはこれで完了 S3 Bucket 作成 tfstate 管理用の S3 Bucket を作成する

#概要 TICK stack とやらを最低限の設定で構築する TICK は以下の Influxdb 改め influxdata ツール群で構成される stack らしい T - Telegraf – Data collection I - InfluxDB – Data storage C - Chronograf – Data visualization K - Kapacitor – Data processing 構成は以下の通り ※公式サイトより #環境 AWS にサーバを2台用意 ip-172-31-17-95 ： Influxdb, Kapacitor, Chronograf ip-172-31-17-94 ： Telegraf バージョンは以下の通り CentOS release 6.7 (Final) InfluxDB v0.10.0 (Beta) Telegraf v0.

概要 今回は CentOS 6.6 に ALMinium をインストールする上で、少し調整が必要だった事例があったのでご紹介します。 もともと ALMinium は Redmine を利用して ALM（アプリケーションライフサイクル管理）を実現するためのフルスタック環境ですが、バージョン管理ツール連携やアジャイル開発支援に便利な各種プラグインを一通りインストールしてくれることから、お手軽な Redmine 構築ツールとして利用されている方も多いかと思います。 反面、様々なプラグインを組み合わせていることから、依存関係維持に伴うメンテナンスの苦労は容易に想像されます。 今現在、ALMinium に含まれている Redmine は 2.5.x 系ですが、本家の安定版は Redmine 3.0.x 系がリリース済み（2015年 2月 19日）というタイミングも相まって、ハマりどころが多くなってい

概要 レポジトリの Dockerfile を更新したら自動で Docker Image をテスト/ビルドして Registry に Push するまでの環境を構築 ※Docker コンテナ内で Docke Image をビルドするため、 Docker in Docker な環境が必要 参考 http://paislee.io/how-to-build-and-deploy-docker-images-with-drone/ 環境 OS : CentOS Linux release 7.1 Docker : 1.8.2, build bb472f0/1.8.2 Docker : Registry: 2.0 drone : 0.3.0-alpha ※Drone, Docker Registry等 のインストールは割愛 ビルドコンテナ alpine ベースで DockerImage を作成 FR

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

概要 CloudFormation を 使用した Kubernetes セットアップツール kube-aws で AWS 上に Kubernetes 環境を構築する 特徴として以下の機能がある ELB integration for Kubernetes Services allows for traffic ingress to selected microservices Worker machines are deployed in an Auto Scaling group for effortless scaling Full TLS is set up between Kubernetes components and users interacting with kubectl 参考 https://coreos.com/kubernetes/docs/latest/kube