こんにちは。コネクト支援チームの@tignyaxです。 みなさま、夏はどう過ごされたでしょうか? 私は、夏が好きなのに今年は夏らしいことが出来なくて寂しいなぁとなっています。。。 さて、今年2020年もエンジニア新人研修を行いましたので、その紹介と講義資料を公開いたします。 2020年のエンジニア新人研修について 基本的には2019年と同じ形*1での実施となりました。 最初の1週間で必修講義をしたあと、新人の皆さんには2週間ずつ3チームを体験してもらいました。 チーム体験のコンセプトは、新人に「興味のあるチームで実際に業務を体験し、配属希望を決める参考になった。」と言ってもらうことです。 各チーム体験では座学や研修を中心にするのではなく、業務体験が中心です。 チーム体験を通して、配属先を検討する材料にしたり、いろんなチーム/人/業務を知ってもらえる機会となります。 必修講義 誰に: 開発/
Red HatでOpenShiftのサポートをしているid:nekopです。 Kubernetes/OpenShiftではEventログはデフォルト1時間から3時間といったTTL設定となっています。Podログをログ基盤へ集約する設定を行っていても、Eventログはetcd内に格納されているリソースであり、Podログではないので、別途対応しないとログ基盤への集約ができません。 良く利用されるものにEventrouterがありますが、これは一つのnamespaceのPodログとして全てのnamespaceのEventログを出力する、という簡易的なものであり、クラスタ管理権限がなかったりマルチテナント環境などの権限管理がしっかりしているクラスタでは利用できず、複数namespaceのEventログがひとまとめになってしまっているのでログの参照権限も問題となります。 そこで、namespace内で
SREのたっち(@TatchNicolas)です。 JX通信社では、月に一度「WinSession」というリリースした機能や検証したリリースについて開発チーム全体へ発表する機会を設けています。今回は自分が前回社内に紹介した「パパッと便利APIを作って5分でお手軽&セキュアにデプロイする」方法について書きます。 TL; DR; Istio/cert-manager/Auth0を使って、任意のコンテナを認証つきで5分でデプロイできる仕組みを作った 設定はアプリケーションごとに独立し、中央集権的なリポジトリに依存しない*1 きっかけ プロダクト間で共通のAPIを認証付きでパパッと作りたいこと、よくありますよね? でも、アプリケーションに毎回認証のための仕組みを組み込むのは骨が折れます。アプリケーションはあくまで、アプリケーションの関心ごとに集中させたい。すると、サイドカーコンテナを使って責務を分
2021/03/01 追記 記載していたリポジトリにあるマニフェスト系があまりに不親切だったので、ちゃんとまとめてみました。 後日、もうちょっとちゃんと記事書こうとは思いますが、大体はREADMEにあるので読んでみてください。 sock-shopをベースにObservability(Prometheus, Loki, Istio(Jaeger, Kiali))とProgressive Delivery&自動負荷試験スタック(Flagger, Jmeter, influxdb)をHelmとKustomizeで詰め込みました。 今回はちゃんと誰もが入れれるようにがんばってみたので、どうぞ。 github.com この内容でCloudNativeDaysOnline2021に登壇することにしています。 event.cloudnativedays.jp 後、随分前ではありますが、本投稿に関連してK
kubectl コマンドを介して Amazon Elastic Kubernetes Service (Amazon EKS) クラスターにアクセスしようとすると、「error: You must be logged in to the server (Unauthorized).」(エラー: サーバーにログインしている必要があります (未承認)。) という認証エラーが発生します。 簡単な説明 AWS Identity and Access Management (IAM) エンティティが Amazon EKS クラスターのロールベースアクセス制御 (RBAC) 設定によって承認されていない場合、承認エラーが発生します。これは、IAM ユーザーまたはロールが aws-iam-authenticator によって使用されるものとは異なる Amazon EKS クラスターを作成した場合に発生し
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 を設定する環境変数 AWS CLI 環境変数を使用すると、別の方法で設定オプションと認証情報を指定できます。このため、スクリプト処理や、名前付きプロファイルを一時的にデフォルトとして設定する場合に便利です。 オプションの優先順位 このトピックで示されている環境変数のいずれかを使用してオプションを指定した場合、設定ファイルのプロファイルからロードされた値は上書きされます。 AWS CLI コマンドラインでパラメータを使用してオプションを指定すると、対応する環境変数または設定ファイル内のプロファイルの値が上書きされます。
設定ファイルと認証ファイルの形式 config ファイルと credentials ファイルは、セクションにまとめられています。セクションには、プロファイル、SSO セッション、およびサービスが含まれます。セクションは、設定の名前付きコレクションであり、別のセクション定義の行が検出されるまで続きます。複数のプロファイルとセクションを config ファイルおよび credentials ファイルに保存できます。 これらのファイルは、次の形式を使用するプレーンテキストファイルです。 セクション名は、[default]、[profile user1]、sso-session などの括弧 [] で囲まれています。 セクション内のすべてのエントリは、setting_name=value の一般的な形式になります。 行の先頭にハッシュタグ (#) を付けると、行をコメントアウトできます。
仮想サーバ17万台、物理サーバ9万台 「ヤフオク!」「Yahoo! JAPAN」を支えるヤフーのITインフラ運用術(1/2 ページ) 国内最大級のポータルサイト「Yahoo! JAPAN」をはじめ、ECサイト「Yahoo!ショッピング」やオークションサイト「ヤフオク!」など、コンシューマー向けWebサービスを数多く運営するヤフー。同社はこれらのサービスを裏で支えるシステム基盤として、大規模なプライベートクラウド環境を自社で構築・運用している。 ヤフーの奥村司さん(クラウドプラットフォーム本部 プライベートクラウドチーム リーダー)が、クラウドインフラの運用管理者向けイベント「Cloud Operator Days Tokyo 2020」で明かしたところによると、その規模は、仮想サーバが約17万台、物理サーバが約9万台。物理サーバのうち2万台がIaaSの仮想化ハイパーバイザーとして使用されて
Kubernetes上の動作している既存のマイクロサービスにIstioを導入する際にハマったポイントについて書きていきます。Istioの検証は1.0系から始めて、現在は1.1.3を使用しています。※ 1 また、Istioの概要についてはこちらのリンク先に書いています。 事前準備当然ではありますが、既存のアプリケーションにIstioを導入する場合、既存のアプリケーションのルーティングを把握している必要があります。Meshに外から中、Meshの中から外、Meshの中のサービス間の通信の流れやその通信で使用しているプロトコルに気を付けなければなりません。ここでのMeshはIstioでEnvoyをInjectするService群の範囲を指しています。Micro Frontendsや認証などのためのプロキシは1度立ててしまえば、普段意識することが少ないはずなので、ルーティングを再度確認した方がよいか
ネットワークトラフィックは、OSI モデルの L4 で負荷分散されます。L7 でアプリケーショントラフィックの負荷を分散するには、Kubernetes ingress をデプロイし、これによって AWS Application Load Balancer をプロビジョニングします。詳細については、「Amazon EKS でのアプリケーション負荷分散」を参照してください。2 種類の負荷分散の違いについては、AWS ウェブサイトの「Elastic Load Balancing の特徴」を参照してください。 タイプ LoadBalancer の Kubernetes Service を作成する際、デフォルトでは AWS クラウドプロバイダーロードバランサーコントローラーにより AWS Classic Load Balancer が作成されますが、AWS Network Load Balancer
GitLab13がリリースされました! 早速バージョンアップしてみました。 が、いつものノリでバージョンアップしようとしたら起動できなかったので備忘録を残しておこうと思います。 ※ちなみに元のバージョンは12.4.2です。 追記)13 => 14へアップデート 構成 docker-composeにてgitlabコンテナとgitlab-runnerコンテナを立ち上げてます 詳細は以下の記事をご覧ください アップデート手順 バックアップ(v12.4.2)取得 gitlabコンテナ内でgitlab-backup createを実行 もしくはホスト側でdocker exec -t gitlab gitlab-backup createを実行 参考:https://docs.gitlab.com/ee/raketasks/backup_restore.html docker-compose down
この記事では、Azure Monitor の次の機能を使って Kubernetes クラスターの完全な監視を有効にする方法について説明します。 メトリック収集のための Managed Prometheus ログ収集のためのコンテナーの分析情報 視覚化のための Managed Grafana。 Azure portal を使うと、すべての機能を同時に有効にできます。 Azure CLI、Azure Resource Manager テンプレート、Terraform、または Azure Policy を使って、それらを個別に有効にすることもできます。 この記事では、これらの各方法について説明します。 重要 Kubernetes クラスターでは大量のログ データが生成されるため、収集するログを選択しないと、大幅なコストが発生する可能性があります。 クラスターの監視を有効にする前に、次の記事を参照
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く