Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
AutoHealing 概要 GCEのmanaged instance-groupにはautohealingという機能がある。 文字通り、ヘルスチェックの結果によってインスタンスを自動修復(再作成)する機能だ。 負荷分散におけるヘルスチェックは、ロードバランサの振り先がHEALTHYかどうかを見るだけで、インスタンスの再作成は行わないが、マネージドインスタンスグループに適用されるヘルスチェックはインスタンスがUNHEALTHYになったら、削除して再作成する。 ヘルスチェックはHTTP、HTTPS、TCP、SSL(TLS)プロトコルをサポートする。 注意 2018/07/11時点では Betaの機能 ヘルスチェックの結果、マネージド インスタンス グループによってインスタンスが削除され再作成される場合、VM インスタンスに関連付けられているインスタンス テンプレートによって新しいインスタンス
こんにちは。 CETというチームに所属している@mihirat です。 OSSのCI/CDとして有名なDroneを Helmを使ってGKE上に構築し、 cloudSQLをバックエンドとして使い、 Github Enterpriseと連携する やり方をまとめます。 最後までこの記事を読むと、Helmも、Droneもわかってしまう美味しい記事となっているはずです。 なお先に白状すると、10分というのはGithubの場合(頑張ればそれくらいいけるんじゃないだろうか…?)で、 Github Enterpriseだと多分ネットワーク周りで作業が多いのでもっとかかります。ご容赦ください。 導入編 Droneって? 公式サイト 無料で使える、Go製のCI/CDツールです。 Github/Github Enterpriseなどと連携でき、リポジトリに簡単な .drone.yml を含めることでPRなどがh
背景 GCP(Google Cloud Platform)いいですよね!AWSより取っつきやすいので最近よく使っています。 その中にGCEというssh接続できるコンピューティングリソースあるんですが、無料枠のf1-microで 以下のGitHubの内容をdocker-compose upしたところ以下のエラーが出たのでシェアです! https://github.com/koyo-miyamura/latestgram ちなみにf1.microのスペックはこちら エラー内容 Installing ffi 1.9.25 with native extensions Gem::Ext::BuildError: ERROR: Failed to build gem native extension. current directory: /usr/local/bundle/gems/ffi-1.9
概要 Dockerコンテナに格納されているAppをGKEのKubernetes Engineで稼働させることを目標とします。 稼働させるAppについては、GCP公式のhello-appを利用します。リクエストに対して「Hello, World!」というメッセージで応答します(port80) 事前準備 Google Cloud PlatformのKubernetes Engineで任意のプロジェクトを作成してください。 プロジェクトに対する課金を有効にしてください。→プロジェクトの請求設定の変更 基本的なgcloud, kubectlコマンドなどの初期設定については公式かk8s : GKEによるKubernetesセットアップ(クラスタ作成まで)〜無料枠〜を参照してください。 ステップ 1: コンテナ イメージを作成する. Kubernetes Engine は、Docker イメージをアプ
夏休みということで、久しぶりにプログラミングに励んでみようと思ってGCPを触ってみたら、いきなりハマったのでメモ。 目的はGoolge Cloud Platform(GCP)におけるGoogle Compute Engine(GCE)の無料枠であるmicroインスタンスを構築してみること。 様々なところで、無料枠のGCE構築は手順はあるので、それに沿って実施したところ、sshdの設定で躓いた。 今、思うと初歩的なところなのだが、意外とハマりそうな気がした。 躓いたところは、Port設定の部分。 ひとまずVMインスタンスを作成した後、セキュリティ対応として、基本的に構築するCentOSのPort設定(デフォルトで22)を変更するというもの。それに合わせてCentOSで標準に備わっているSELinux と iptablesを無効化していく。 SELinux と iptablesの無効化 ここで
. ├── build.gradle ├── Dockerfile ├── gradle │ └── wrapper │ ├── gradle-wrapper.jar │ └── gradle-wrapper.properties ├── gradlew ├── gradlew.bat ├── settings.gradle └── src ├── main │ ├── kotlin │ │ └── com │ │ └── sugikeitter │ │ └── kotlinboot │ │ ├── controller │ │ │ └── HelloController.kt │ │ ├── data │ │ │ └── Hello.kt │ │ └── KotlinbootApplication.kt │ └── resources │ └── application.yml └──
gceを使ってるとインスタンスの容量が足りなくなることがある google compute engineディスクの容量を増やす方法を試した ディスクサイズを変更する google cloud console上でストレージ設定の変更 インスタンス一覧のページより https://console.cloud.google.com/compute/instances 設定を変更したいインスタンスを選択、詳細ページより ブートディスクとローカルディスクから、適当なディスクを選択 ディスク画面から、編集をクリックして 任意の数値に変更して、保存をクリック gceインスタンスでマウントボリュームの設定 以下はgce上で操作している /の容量は30Gになっている $ df -h Filesystem Size Used Avail Use% Mounted on udev 7.4G 0 7.4G 0%
はじめに マルチクラウドの環境おいてGCPのCompute EngineからVPN接続されたAWSのRoute53のPrivate DNSで名前解決を行い、AWS EC2のインスタンスへアクセスする設定について記載していきます。 この記事ではGCPとAWSの設定がすんでいることを前提としています。VPNの設定に関しては以下の記事が参考になるかと思います。 Amazon VPCとGoogle Compute EngineをVPN接続する [IPSec-VPN] クラウド間(GCP⇔AWS)通信 問題点 GCPとAWSのVPNの設定を行い、いざEC2とGCE間での通信行おうとして、とりあえずpingで接続確認。IPでの接続確認はVPN設定で当然行えるのだけれど、ドメインでの接続確認が... 上記ドメインの名前解決はAWSのRoute53のPrivate DNSに設定されていて、そこで名前解決さ
vCPU1(3.5GB) gcloud beta compute --project=komitest-XXXXXX instance-templates create instance-template-1 \ --machine-type=n1-standard-1 --network=projects/komitest-XXXXXX/global/networks/default \ --network-tier=PREMIUM --maintenance-policy=MIGRATE --service-account=xxxxxxxxxxxx-compute@developer.gserviceaccount.com \ --scopes=https://www.googleapis.com/auth/pubsub,https://www.googleapis.com/auth/
cPanelは最も多く使われているGUIサーバー管理ツールです。欧米では非常に人気がある唯一無二のサービスなのですが、日本ではあまり多用されていないようです。サービス名称としては「WHM/cPanel」という書き方をしますが、「WHM(Web Host Manager)」はそのサーバーにて運用される個々のホスト達を作成したり設定可能範囲を管理する親ツールです。これに対し、「cPanel」はWHMで管理された個々のホストを管理する子ツールです。すなわち、「WHM」が「ホスティングサービス運営管理者」、「cPanel」が「店子としての各ホストの管理者」という位置付けになります。30日間のお試し期間があり、月額15ドルから(ホストの種類や管理状況により異なる)の費用で使えます。 cPanelウェブサイト: https://cpanel.com/ 私は理系院卒で学生時代に大学のネットワーク管理者を
始めに Chromebook愛用者向けの記事です。 Chromebook大好き。WindowsよりもUbuntuよりもArchよりもMacよりも好き。 シンプルで使いやすくてすごくいい。 そう思ってやまないのですが、プログラミングに関しては色々と悩むことが多く困ってました。 Chromebookのプログラミング環境について とりあえず現状とりうる手段と感じたメリット、デメリットを挙げてみます。 Cloud9等のクラウドIDEを使う メリット:特にローカルにインストールはいらない。(Chromebookらしい!!) デメリット;対応した言語以外を使うのがきつい。スペックが低い。スペック上げると案外値段が高い。 croutonでローカルにUbuntuをインストール メリット:Cloud IDEでは対応していないような言語にも対応できる(Elixirとか) デメリット:ローカルの管理が面倒くさい
経緯 動かしているものは秒単位で変動する金融APIへ接続し発注するシステム。システムそのものの詳細はここでは省略させていただきます。 heroku scheduler の料金について調べた時にはここまで分からなかったので、具体的な事例として共有します。 スキルのバックグラウンド 僕は非エンジニアであるが、サービスを作りたくて触っていたら一通りコードが書けるようになった(Rails はじめて半年とか) Heroku も触っていたらそれなりに使えるようになった まとめ 事前に分かっていたこと 24時間稼働のtaskは worker を使うこと schedular は短時間のバッチ処理に利用すること 事前に分かっていなかったこと schecular の料金体系 新たに分かったこと one-off dyno は起動単位で課金される 複数のスケジュールが立ち上がり、それぞれ長く起動すると起動ごとに課
背景 ローリングアップデートは、システムがダウンしないように少しずつアップデートをする手段です。 古いバージョンのコンテナを残しつつ、新しいバージョンのコンテナを生み出すことで実現します。 Blue Green Deploymentと同じような感じですが、新旧システムが混在する時間が存在します。 kubernetesではrolling-updateコマンドがありますが、現在はより上位概念のdeployemntを使うのが推奨されているようです(http://kubernetes.io/docs/user-guide/rolling-updates/)。 以下のようにdeployment.ymlを設定すると、ローリングアップデートを実行してくれます。 この設定でapplyをするだけで、変更後のコンテナが生まれ古いコンテナが消えてゆきます。 この場合、新コンテナ内の準備が整うまでアクセスできない
本日、かしゆかの誕生日です、どうぞみなさまお祝いください。 さて、本日の内容です。 Container Registry が GA になったよ!! 2017/9/5 の changelog で Container Registry GA - Deploy Docker images to Herokuと公開されたとおり、これまでβサービスとして提供されていた Docker 向けコンテナサービスが、本番向けにリリースされました。 これまで buildpack の制約や、docker でせっかく準備した開発サイクルのために、Herokuの利用を躊躇されていたみなさまには、朗報です。はやいところ、Heroku Pipelines 上で Heroku CI つかって、Docker のCI/CD まわしたいですね!! Heroku は世界を支配しますよ!! (もしかすると、https://devce
AWS Private link について 先日 AWS Private linkという機能が発表されました。 https://aws.amazon.com/jp/blogs/aws/new-aws-privatelink-endpoints-kinesis-ec2-systems-manager-and-elb-apis-in-your-vpc/ これまでの方式(DynamoDB,S3)はエンドポイントのゲートウェイ経由で各サービスのAPIに接続する形でしたが 新しい方式ではエンドポイントがENIに紐付き、VPCのプライベートIPを持つかたちになります。 この方式のメリットとしては ・セキュリティグループでエンドポイントへのアクセスを管理できるようになる ・エンドポイントにDirect Connectを介してアクセスすることができる というのが大きいかなと思います。 Private li
サーバサイドを Go で WebAPI として独立して作り、フロントは Vue.js で SPA チックに作り、Static な成果物(HTML/CSS/JS)を Go バイナリに内包して Heroku で動かすメモです。 サンプルのソースコードはこちらです。 https://github.com/zaru/go-vuejs-heroku 前提条件 Go 1.9+ パッケージ管理: dep DBマイグレーション: pressly/goose Vue.js 2.5+ vue-cli ビルドツール: webpack Heroku PostgreSQL Redis デプロイの動作フロー git push heroku master で Heroku にデプロイ デプロイ dep で必要パッケージをインストール npm で必要パッケージをインストール Vue.js を webpack でビルド G
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く