こんにちは WESEEK でわりと何でもやっている haruhikonyan です。
今やデファクトとなりつつある kubernetes(以下k8s) ですが読者の皆様は k8s のオペレーションをする際のコンテキスト切り替えにはどういったものを使っていますでしょうか。
以下のようなものがあると思います。
kubectl config use-contextkubie ctx
もちろん他にも選択肢はあるかと思います。
コンテキスト切り替えと言えば、本番とステージングやテスト、開発でコンテキストを分けて運用をしているシステムは多くあるのかなと思います。
その中でステージングとかの設定を変更する際に、現状の本番の設定を確認するためにコンテキストを一時的に切り替えて設定を確認した後、またステージングにコンテキストを戻して作業を続けるという経験あるのではないでしょうか。
この記事は、2021/6/24 に行われた WESEEK Tech Conference の内容です。
弊社が開発するSaaS型社内wiki・ナレッジベースサービス GROWI.cloud で、過去に発生した障害をピックアップしてご紹介します。
思い出すのもツラいところがありますが、発生した障害の中でも比較的大きいものを紹介しておりますので、
当時感じたツラさを感じてください。(^^;
前回よりも障害の規模は大きめです。
障害に関連するシステム情報をはじめ、原因と対策は技術・運営の観点を紹介してますので、次の点が役に立つかもしれません。
この記事は、2021/5/27 に行われた WESEEK Tech Conference の内容です。
弊社が開発するSaaS型社内wiki・ナレッジベースサービス GROWI.cloud で、過去に発生した障害をピックアップしてご紹介します。
思い出すのもツラいところがありますが、発生した障害の中でも比較的大きいものを紹介しておりますので、
当時感じたツラさを感じてください。(^^;
障害に関連するシステム情報をはじめ、原因と対策は技術・運営の観点を紹介してますので、次の点が役に立つかもしれません。
この記事は、 2021/4/22 に行われた WESEEK Tech Conference の内容です。
Google Compute Engine のプリエンプティブルインスタンスを利用したクラウド利用料を節約するお話をしました。
Google Cloud Platform 上で稼働している GROWI.cloud を実例に上げつつ、節約額、稼働率の運用実績についてもご紹介しました。
この記事は CircleCI Advent Calendar 2019 の 19 日目の記事です。
拙稿となりますが Ruby on Rails, Vue.js によるモダン WEB アプリケーション 実践編 (その2) にて GitHub Action を使って k8s 上で動作する Ruby on Rails アプリケーションを CI/CD する Workflow を作ったので、同じ機能を CircleCI で作ってみることにします。
尚、Rails アプリケーションを前提としてますが、k8s の deployment manifest で定義されたアプリケーションであれば概ね流用できると思います。
Kubernetes時代の CI/CD Jenkins Xとは？|前編 で予告した通り、本記事では実際に Jenkins X をインストールし、どのような構成でクラスタが構築されるのかを見ていきたいと思います。
「SEROKU フリーランス(以下、SEROKU)」の中の人をやっている kouki です。
今回は 社内 Kubernetes 実験環境をRancher 1.6から 2.0にアップデートして復活させた話 の中でお話しした「2.0で行ったトラブルシューティング」の「グローバル IP とプライベート IP 2つの足(NIC)を持つサーバを Kubernetes クラスタのネットワークに所属させることができない (Calico ネットワークが確立されない)」という件についてお話させていただきます。
2018年3月に Jenkins を開発している CloudBee から「Jenkins X」というプロダクトが発表されました。
https://jenkins.io/blog/2018/03/19/introducing-jenkins-x/
社内で検証する機会がありましたので、この記事では前後編に渡って、CI/CD の解説から、Jenkins X を実際に使うまでに必要となった道のりや、使ってみての感想を書いていきたいと思います。
当記事は 2018 年に発生した事例の紹介記事です。現在は Rancher 2.0 で快適に動作しております。
kouki です。
今回、その実験環境が壊れてしまったので、Rancher 2.0 にアップデートして復活させたお話をさせていただこうと思います。
SEROKU の開発フローでは、開発用のリポジトリに Mercurial を用い、各機能実装ごとにブランチを用意した上で開発を行っています。
その上でさらに、社内に Kubernetes クラスタを用意して、ブランチごとにデモ環境を立ち上げられるような仕組みを整備しています。
関連記事
Kubernetes時代のCI/CD Jenkins Xとは?-前編
当初は、各ブランチごとにドメインを作成し、Let’s Encrypt による SSL 証明書を発行していたのですが、並行で開発するブランチ数が多くなってくるとやがて rate-limit に当たるようになりました。
(参考: Rate Limits – Let’s Encrypt – Free SSL/TLS Certificates)
今回は、それを回避するために必要となった、Kubernetes クラスタ上で Let’s Encrypt を用いたワイルドカード証明書を自動発行・更新できる基盤の作り方についてご紹介します。
弊社では AWS Route 53 でドメインを管理しているため、本記事では Route 53 を利用したドメインを対象とします。
