はてなブックマーク

※ 2020/04時点でIngress for internal load balancingは公開されたものの、未だプレリリースのステージにあります。Rapid channelのクラスターでしか動かないため、Stableに降りてきたら手順を更新予定です。 はじめに この記事はZOZOテクノロジーズ #1 Advent Calendar 2019 22日目の記事です。 昨日の記事は @takanamitoさんによる「teyuに届いたPullRequestで使われているRubyの高速化手法」でした。 みなさん、GKE完全に理解していますか？僕は定期的に完全理解しています。 今回は、GKEに内部ロードバランサーをデプロイする方法についてご紹介します。 Kubernetesのネットワークの世界のおさらい 内部ロードバランサーの話をする前に、まずはKubernetesのネットワークについて簡単に振

はじめに これは、ZOZOテクノロジーズ #4 Advent Calendar 2019 13日目のエントリーです。 前回の前編記事に引き続き、Airbnbのエンジニアたちが経験したクラスターでのやらかしをあれこれご紹介します。 6. Where's my Custom Resource?（ワイのカスタムリソースはどこに？） AirbnbではKubernetesのCustom Resourceをよく使用しています。 特に、Kubernetesクラスターの外部にあるが、ストレージ、ダッシュボード、アラート、IAMロールなどのAWSリソースなどのサービスに関連付けられているリソースを追跡するために使っています。 こうしたCustom Resourceを使う上で大変なのが、「そのリソースがいつ利用可能になったか」や、「そのリソースに関する変更がいつ反映されたか」を検知することです。 最初のうちは

はじめに これは、ZOZOテクノロジーズ #4 Advent Calendar 2019 12日目のエントリーです。 今回はKubeConに参加して面白かったセッションの1つである「10 weird ways to blow up your Kubernetes(Kubernetesをぶち壊す10の奇妙な方法)」をご紹介します。 この他にも、「Airbnbの事例に学ぶKubernetesとマイクロサービスのあり方 @ KubeCon Seattle 2018」という記事も執筆しているので、合わせてご覧ください。 また、このセッションのスピーカーであるMelanie Cebulaは、CloudNative Days Tokyo 2019のキーノートスピーカーとしても来日し、登壇しています。 後編書きました！ セッションの背景 セッションスピーカーであるMelanieとBruceは、Airbn

Notable information マイナーバージョンについては最新のバージョンの他、直近3バージョンについてパッチリリースが入ります。 2019年12月現在では1.17がUpstreamの開発バージョン、1.14-1.16がパッチリリースの対象です。 Kubernetesの基本的なアップデートサイクルは、3ヶ月に1回のマイナーバージョンリリースなので、このまま行くと12月の半ばには1.17がリリースされる見込みです。 Kubernetesのバージョンリリース管理については「SIG-release」によって管理されています。 2019年にあった大きなアップデート/ニュース 前提として、全部のリリース、アップデートを追ってしまうと本当にきりがないくらい大量の情報があるので、主に記事として取り上げられたか、そのくらい大きな規模の情報について取り上げていきます。 1.14.0における大きなア

はじめに これは、Amazon EKS Advent Calendar 2019 5日目の記事です。 今回は、Amazon EKSをサクッと使おうと思ったら思いの外ハマったことを振り返りつつシェアしようと思います。 EKS on Fargateについて知りたい方はこちらも合わせてどうぞ！ ハマったこと 1. 構成管理に使うべきツールの正解がわからない EKSを構築、運用する上で構成管理のコストは無視できない概念です。何より、日々の運用が大変なものは選びたくありません。 今年の10月にこちらのアナウンスで公式ツールに採用された今、特に大きな理由がない限りはeksctlを使っておけば安牌のように思います。 EKSの技術選定をしていたのは今年の夏頃なのですが、当時はeksctlは公式のツールではなくサードパーティのツールとして提供されていました。この時点でEKSの構成管理を行うには大きく分けて3

TL;DR Kubernetesに脆弱性が見つかった(CVE-2019-11253) Severity7.5なので高め(昔からクラスター運用してる場合はなるはやで上げよう) Kubernetes API Server(kubectlがアクセスするエンドポイント)がPublic IPの場合は特に注意しよう 脆弱性の内容 特定の条件を満たすマニフェスト(YAML or JSON payload)を食わせるとKubernetesのマスターコンポーネントであるKubernetes API Serverが応答不能になる。 1.14.0以降のバージョンで新規に作られたクラスターの場合、デフォルトのRBACの設定が変更されており、認証済みユーザーのみがこの脆弱性を突くことが出来るようになっている。つまり、脆弱性の範囲が限定的になる(クラスターに対してYAMLを送るためにユーザー情報を持っているクライアン

はじめに この前至高のDockerイメージ生成を求めて -2019年版-を書いて多くの反響をいただきました。 この記事の中で「BuildKitを使うと軽量なコンテナのビルドが高速にできるようになる」と書いたのですが、実際のところ2019年現在において、Docker Composeの正式リリースではまだこちらの機能が使えません。 Docker for MacのEdgeチャンネルで2.1.5.0(40323)が降ってきて、BuildKitのComposeが使えるようになってました！！！！やったぜ！ これは、Docker ComposeではDockerのAPIと通信するのにPythonのライブラリであるdocker-pyを使っていて、こちらのメンテナンスが遅れていることが理由でした。 Docker ComposeでBuildKitは使えないのか 結論から言うと、次のリリースで使えるようになります

この記事は@yugui氏の書いた至高のDockerイメージ生成を求めてに感謝しつつ、記事が投稿された当時には無かったさまざまな事情を組み込んで再度まとめたものである。 良いDockerイメージ 良いDockerイメージとは何だろうか。Dockerの利点は次のようなものだから、それを活かすイメージが良いものであるに違いない。 ビルドしたイメージはどこでも動く 適切にインストールされ、設定されたアプリケーションをそのままどこにでも持っていける。 コンテナ同士が干渉し合うことはないので、任意のイメージを互いに配慮することなく柔軟に配備し実行できる 必要のないサービスがコンテナ内で走っていないので、セキュリティの向上に資する イメージの転送が効率的である ベースイメージ部分は一度送ればいちいち再転送する必要がないので、ベースイメージを共有する複数のイメージを効率的に転送できる 標準のレジストリAP

Cloudflareが作成したrust製のQUICライブラリ、quicheを使ったcurlでのHTTP/3通信は以前の記事を使って実現できましたが、ngtcp2とnghttp3を使ったcurlのビルドが上手くいかず、放置してました。 今日やってみたら動くようになってたのでうれぴーって感じです。 こんなかんじ。 $ docker run --rm -it inductor/curl-quic-ngtcp2 # curl --http3 https://facebook.com/ curl --http3 https://www.facebook.com/ -v -s -o /dev/null * Trying 31.13.82.36:443... * Connect socket 3 over QUIC to 31.13.82.36:443 * QUIC handshake is compl

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 Kubernetesは、コンテナを基としたインフラのオーケストレーションツールです。 非常に多機能で、宣言的な記法でのインフラコード管理によって、柔軟かつ堅牢なインフラストラクチャを構築することができます。その一方で、(Kubernetesのみの知識に関わらず)非常に学習コストが高いという側面も持ち合わせています。 このエントリーでは、Kubernetesを知る上でその前提知識として必要そうなキーワードと、なぜ必要なのかという簡単な説明を書いていきます。 項目については、自分自身がハマったり困ったことがベースになっているため、もし

概要 DockerのデーモンをLinux上で実行するためには、通常はroot権限を渡す必要がありましたが、Docker Meetup TokyoのオーガナイザーをやっているNTTの須田さんによるこちらのコミットによって、Dockerをroot権限なしに実行できるようになりました。 より詳しくは、Dockerのエンジニアリングブログを御覧ください。 試してみた Rootless dockerのインストール 試した環境 Ubuntu 18.04 $ curl -sSL https://get.docker.com/rootless | sh % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 54.0M 100 54.0M 0 0 9624

参考までに、Kubernetes単体の要件としては、API Serverを動かすのには1GB以上のRAMがあって、x86_64のCPUを使っているのが「望ましい」とドキュメントにはそれとなく書かれていたりします。ですが、実際にはもっと高スペックなマシンを利用するケースが多いはずです（無論、規模によります）。 それと比べ、k3sは非常に小さな環境でも動作します。どうしてなのでしょうか？ いくつか、特徴的な部分をピックアップしてみることにします。 Kubernetesの中で利用シーンの少ない機能を削っている Kubernetesには、後方互換性のために残しているレガシーな機能やAPIや、新たに追加されようとしているAlphaやBetaの機能が多数存在します。 k3sでは、軽量化のためにそれらの機能を削っています。 デフォルトのetcdをsqlite3にしている etcdは非常に高い信頼性を誇る

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに こちらは、ZOZOテクノロジーズアドベントカレンダー 20日目の記事です。 KubeConに参加したSREチーム所属のへっぽこエンジニア@inductorが、2日目のKeynoteであるAirbnbの事例をみて学んだことをまとめます。 KubeConの当日の様子は、僕個人のブログや、弊社テックブログに後輩がまとめていますので、そちらもご覧ください。 TL;DR 1年前にK8sを導入していまやサービス全体の40％のアプリケーションがK8s上で動いてる 多数のマイクロサービス・チームを抱えるため、Kubernetesの管理に必要な

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 インターネットに関する技術の標準化を司る、IETF(Internet Engineering Task Force)のWG(Working Group)において、HTTP-over-QUICが正式にHTTP/3という名前になることで合意が取れました。(ゆきさんからのご指摘内容を修正しました) しかし、そもそもこのQUICやHTTP/3って何なんでしょうか？ Webに関わる僕たちエンジニアにとってどういう関わり方をするのか、考えてみました。 この記事は怪文書ですので、雑と書いてあるところは私見として軽く流してください。 追記 詳解H

About this article 今年の4月に、AWS Secrets Managerというサービスがアナウンスされました。 既に触っている方もいらっしゃるとは思いますが、あまり記事がなかったので、個人的なメモも含めて触ってみたときにやったことをここに記します。 About AWS Secrets Manager AWS Secrets Managerは、 データベースの認証情報やAPIのシークレットキーなどのコードに直接書きたくないデータを簡単に管理できるサービスで、アプリケーションからトークンを叩いてアクセスする際などに使えます。 クラスメソッドさんの記事にも詳しく書かれており、以下のような特徴があります(以下抜粋) 各種アプリケーションやITリソースのアクセスに必要なシークレット情報を一元管理 ユーザーはAWS Secrets Manager API経由でアクセスするため、各種シ

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

はじめに これは、mohikanz Advent Calendar 2017の6日目の記事です。 mohikanzについては、カレンダー1日目の記事を御覧ください。 導入のきっかけ 私の所属する会社では、情報共有ツールにDocbaseを利用しております。 esaを使うグループも一部あったりはします。 私が入る前にはQiita:Teamを利用していた時期もあったようですが、どのような経緯で変更されたのかなどについては不明です。 mohikanzでは日々チャットで様々なことが話題に上がりますが、Slackのプランが無償である点や、チャットには即時的な効果がある反面、流れてしまうとあとから追っていくのが難しくなるというデメリットもあります。 技術的な話題であったり、あとから保存しておきたい話、mohikanzで開催するイベントの話など、pinだけではきりがない！ということが度々見受けられました。

これは、http2 Advent Calendar 2016の11日目の記事です。前日は @flano_yuki さんの投稿分でした。 導入編ということで、今回はHTTP/2とQUICについての簡単な概要でも書くことにします。 はじめの前のおまけ これは是非入れておきましょう。 はじめに 昨年、HTTP/2が正式に文書化され、Web界隈では大きな話題となりました。 早くもChromeでは従来のSPDYを使った通信はすっかり封印され、 現在はHTTP/2またはQUICを使った通信がサポートされています。 そこで、HTTP/2とQUICについて、一旦おさらいしてみたいと思います。 HTTP/2 元々はSPDY(スピーディ)という名前で、Googleを中心としたワーキンググループによって開発されていた、 従来のレガシーなHTTP通信を向上させるための新しい通信プロトコルです。 簡単に言えば、実に

去年の暮れにPHP7がリリースされ、少しずつではありますがその速さに驚く声がちらほら聞こえます。 身内用にownCloudを運用してみようと思った時に、せっかくなのでいろいろ新しいことを試してみようと思ったのですが、まだこの構成でやったというリソースがあまり見当たらなかったので次回困らないよう手順にまとめてみました。 今回はメモ程度にサーバへのownCloudの導入と、HTTP2有効化 + Let's EncryptでSSL証明書の発行までを一括の流れでつらつらと書いていこうと思います。 初心者でも運用が開始できるように少し冗長に書いた部分もありますが、何かご指摘、改善点等あればご教授ください。 ※こっそりアドベントカレンダーに掲載させていただきました。 ownCloudとは いわゆるDropboxやGoogle Driveのようなオンラインストレージです。特徴としては・・・ オープンソー