この記事は、著者の許可を得て配信しています。 https://panelbear.com/blog/boring-tech/ 注:この記事で書かれている考え方は、過去に何度も取り上げられています。長年にわたって私の視点に大きな影響を与えてきた記事の一つに、McKinley氏の「Choose Boring Technology(退屈な技術を選ぶ)」というものがあります。以下では、私自身の経験からこのトピックを探り、最近のプロジェクトでKubernetesを使うことになった経緯を紹介します。 長年にわたり、私は多くのエンジニアが会社の成功や失敗の多くを技術的な選択が原因であると主張する傾向があるところを見てきました。私にももちろんそういう時もあります。それはしばしば正当化されますが、大多数のスタートアップ企業にとって、プログラミング言語、フレームワーク、あるいはデータベースの選択はそれほど重要
はじめに Kubernetes 上のアプリケーションに対して、curl や tcpdump など使い慣れたツールを使ってデバッグを行いたいと思う場合があるかと思います。kubectl exec を利用するとコンテナ内のコマンドを実行することができ、従来 ssh で行っていたデバッグに近いことが可能になります。一方、コンテナには必要最低限のものしか含めないことがベストプラクティスとなっているため、使いたいコマンドが含まれていないこともあるでしょう。 本記事では、kubectl exec を主としたデバッグの方法と、コンテナに使いたいコマンドが含まれていない場合や kubectl exec が利用できない場合の対応方法などについて説明します。確認は Kubernetes v1.8 で行い、コンテナランタイムは Docker を前提としています。 kubectl exec を使ったデバッグ ku
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く