https://wenhan.blog/ Recent content on Wenhan blog Hugo -- gohugo.io ja-JP Thu, 01 May 2025 23:49:19 +0900 https://wenhan.blog/posts/20250501_konnect_ecs_gui/ Thu, 01 May 2025 23:49:19 +0900 https://wenhan.blog/posts/20250501_konnect_ecs_gui/ Kong Konnect のData Planeとして、AWS ECS（Elastic Container Service）Fargate を使ってマイクロサービスをデプロイし、API Gateway環境の構築方法を紹介します。 準備するもの AWSアカウント Kong Konnectアカウント 構築手順 Kong Konnect側 Konnectにログインし、Gateway manager -> Data Plane Nodes -> Configure data planeの順でData Plane作成画面にきて、Generate Certificateをクリックしてdocker runのコマンドが生成されます。このコマンドのパラメータが以降使いますのでコピーしていきます。 証明書が生成されたらKonnect側の作業が終わります。この証明書とkeyに改行が入っています、後でECSの環境変数として設定するため、下のコマンドで一行になるように変更します。 1 awk 'NF {sub(/\r/, ""); printf "%s\\n",$0;}' tls.key AWS ECS側 コンテナーの定義 AWS ECS -> Task definitions -> Create new task definition with JSON でコンテナーの定義を行います。 利用するJSONは以下になります。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 { "family": "kong-data-plane", "networkMode": "awsvpc", "containerDefinitions": [ { "name": "kong-data-plane", "image": "kong/kong-gateway:3. https://wenhan.blog/posts/20250415_kong_serverless/ Tue, 15 Apr 2025 23:49:19 +0900 https://wenhan.blog/posts/20250415_kong_serverless/ Pre-function Plugin 解説と実用サンプル Kong Gatewayは多機能なAPIゲートウェイですが、ちょっとした処理をサーバレス関数として内蔵できることをご存知でしょうか？ 今回は、Luaスクリプトを使ってリクエストのBodyからUUIDを抽出し、Headerに追記＆ログ出力するという実用的なサンプルをご紹介します。 Pre-function Pluginとは？ 公式ドキュメントにある通り、pre-functionプラグインはリクエストをAPIに送信する前にLuaで処理を記述できる柔軟な機能です。 用途は多彩で： 条件分岐によるフィルタリング ヘッダー／ボディのカスタマイズ 軽量ログやモニタリング処理 メンテナンス用の簡易ブロック処理 など、プラグイン化するほどじゃないけど、ちょっと処理したいというニーズにぴったりです。 実用例 今回は、リクエストボディにあるUUIDを抽出してヘッダーとログに追記する機能をServer Less機能で実現します。 処理の流れ リクエストBodyからUUIDを抽出（JSONパース） UUIDがあれば x-uuid ヘッダーに追記 抽出結果をログに出力（File Logプラグイン使用） 前提準備：サービスとルートを作成 1 2 3 4 5 6 7 8 # サービス作成 curl -i -X POST http://localhost:8001/services \ --data name=mock-service \ --data url=http://httpbin.org/anything # ルート作成 curl -i -X POST http://localhost:8001/services/mock-service/routes \ --data 'paths[]=/uuid-test' File Log Plugin でログ出力（標準出力へ） 1 2 3 curl -i -X POST http://localhost:8001/services/mock-service/plugins \ --data "name=file-log" \ --data "config. https://wenhan.blog/posts/20250325_kong_graphql_mngm/ Tue, 25 Mar 2025 23:49:19 +0900 https://wenhan.blog/posts/20250325_kong_graphql_mngm/ GraphQL のおさらい GraphQL は、Facebook が開発した API クエリ言語であり、従来の REST API よりも柔軟にデータを取得できる仕組みを提供します。 GraphQL の特徴 単一のエンドポイント: REST API では複数のエンドポイントが必要ですが、GraphQL では 1 つのエンドポイント (/graphql) に対して異なるクエリを送信できます。 必要なデータのみ取得: クライアントが必要なフィールドだけを指定して取得できるため、不要なデータ転送を防げます。 型システム: API のスキーマが型で定義されており、データ構造を明確に把握できます。 例えば、https://countries.trevorblades.com/ という GraphQL API に対して、以下のようなクエリを送信すると、日本の国情報を取得できます。 1 2 3 4 5 6 7 { country(code: "JP") { name capital currency } } このクエリを curl を使って実行する場合: 1 2 3 curl -X POST https://countries.trevorblades.com/ \ -H "Content-Type: application/json" \ -d '{"query": "{ country(code: \"JP\") { name capital currency } }"}' レスポンス: https://wenhan.blog/posts/20241224_kong_101_mtls/ Tue, 24 Dec 2024 23:49:19 +0900 https://wenhan.blog/posts/20241224_kong_101_mtls/ API通信におけるセキュリティは、システムの信頼性を保つ上で非常に重要です。本記事では、Kong API Gatewayを使用して、mTLS（Mutual TLS、相互TLS）を設定する方法を詳しく解説します。特に、「Client -> Kong」と「Kong -> Upstream API」の2つの通信パスでのmTLSの設定方法について取り上げます。 mTLSの基礎知識 mTLSとは、TLS（Transport Layer Security）を拡張したプロトコルで、通信の両側（クライアントとサーバー）が互いに証明書を使って認証を行います。通常のTLSはサーバー側の認証だけを行いますが、mTLSでは以下のようなプロセスが追加されます： サーバー認証：クライアントは、サーバーが信頼できる証明書を持っていることを確認します。 クライアント認証：サーバーは、クライアントが信頼できる証明書を持っていることを確認します。 この双方向の認証により、より安全な通信が実現します。 Kong API Gatewayで実現するmTLS通信 Kong API Gatewayを使えば、以下の2つの通信経路でmTLSを簡単に実現できます： クライアント → Kong API Gateway Kong API Gateway → Upstream API Client->KongのmTLS設定 クライアントからKong API Gatewayへの通信にmTLSを実装するには、Kongの「mTLS Plugin」を使用します。以下は手順の概要です。 管理者がクライアント認証用のCA証明書をKongに設定 クライアントはリクエスト時に自分の証明書をKongに提示 Kongがクライアント証明書を検証し、安全な通信を許可 CA証明書を登録 Clientの証明書を検証するためのCA証明書をvalutに登録 1 2 3 4 5 6 7 8 9 curl http://localhost:8001/ca_certificates -F cert=@ca.crt { "cert": "<PEM_CERT>", "id": "c383d81a-bffc-4e2a-b0d3-ac56b441a07b", "cert_digest": "3e9099b5015e8f486c00bcea9d111ee721faba355a89bcf1df69561e3dc6325c", "tags": null, "created_at": 1607347576 } mTLSプラグインを有効化 先ほど作ったca_certificateを利用して、mTLSプラグインを有効化します。ここではグローバル範囲に指定しています。 https://wenhan.blog/posts/20241223_kong_101_req_res_trans/ Mon, 23 Dec 2024 23:49:19 +0900 https://wenhan.blog/posts/20241223_kong_101_req_res_trans/ 前書き 現代のアプリケーション開発では、APIは他のシステムやサービスと連携するための重要な基盤となっています。しかし、異なるシステム間でAPIの要件が合わない、データ形式が異なる、セキュリティ要件が満たされていない、といった課題は頻繁に発生しています。こうした状況において、APIゲートウェイを活用することが、リクエストとレスポンスを柔軟に変更する最も効果的な方法です。 Kong GatewayのようなAPIゲートウェイは、単なるAPI管理ツールではありません。トラフィックの流れを制御する中で、リクエストやレスポンスの内容をカスタマイズする強力な機能を提供します。たとえば、次のような項目を変更することが可能です： ヘッダー クライアントから送信されたリクエストヘッダーに認証情報やカスタム値を追加したり、レスポンスヘッダーを編集してキャッシュ制御やセキュリティに関する情報を含めたりすることができます Bodyの変換 リクエストBodyを加工して上流のサービスが期待する形式に変更したり、レスポンスBodyの内容をフィルタリングして不要なデータを削除することが可能です ステータスコードの変更 APIの動作に応じてステータスコードを変更し、エラー処理やリダイレクトの挙動を制御することもできます データフォーマットの変換 古いシステムがXMLを要求するが、新しいシステムがJSONを利用している場合、APIゲートウェイでデータフォーマットを動的に変換することで互換性を確保できます 暗号化と復号化 セキュリティ要件に応じて、リクエストやレスポンスデータを暗号化または復号化することで、通信の安全性を向上させることができます これらの変更はすべて、APIのクライアントやバックエンドに手を加えることなく実現できる点が最大の利点です。APIゲートウェイはシステムの境界で操作を行うため、変更内容が他のシステムに影響を与えるリスクを最小限に抑えながら、柔軟なカスタマイズを可能にします。 Kongでリクエストとレスポンスを変更する方法 この記事では、これらの変更をKong Gatewayでどのように実現するのかを具体的に解説していきます。 Request transformer / Response transformer プラグインの紹介 Kong Gatewayが提供するRequest TransformerおよびResponse Transformerプラグインは、リクエストやレスポンスの内容を簡単にカスタマイズするためのツールです。このプラグインを利用すれば、リクエストやレスポンスのヘッダーやBodyを加工・変換し、システム間の調整や特定のAPI要件に応える際に役立ちます。 主要な機能 Request Transformer プラグインの主な機能 リクエストヘッダーの追加、削除、上書き クエリパラメータの追加、削除、上書き リクエストBodyの追加・削除 Response Transformer プラグインの主な機能 レスポンスヘッダーの追加、削除、上書き レスポンスBodyの不要部分を削除 これらの機能を組み合わせることで、APIトラフィックを柔軟に制御することができます。 Plugin設定 まず、テスト用のServiceとRouteを作成します。今回はリクエストをそのままレスポンスするAPIを利用し、変更されたリクエストを確認します。 1 2 3 4 5 6 7 curl -i -X POST http://localhost:8001/services/ \ --data name=echo_service \ --data url=http://httpbin.org/anything curl -i -X POST http://localhost:8001/services/echo_service/routes/ \ --data name=echo_route \ --data paths=/echo 次、request transformerのプラグインを有効にし、以下のルールを設定しました。 https://wenhan.blog/posts/20241216_kong_jwt_ultra/ Mon, 16 Dec 2024 23:49:19 +0900 https://wenhan.blog/posts/20241216_kong_jwt_ultra/ (https://tech.aufomm.com/the-ultimate-guide-of-using-jwt-with-kong/ より翻訳) :::note この記事は「究極の」ガイドとまでは言えないかもしれませんが、JWT 検証に使える公式の Kong プラグインを徹底的に解説することを目指しています。読み終えるころには、利用可能なオプションを全体的に理解し、それぞれのユースケースに最適なプラグインを選べるようになるはずです。 ::: 背景 JSON Webトークン（JWT）は、Web開発に欠かせない要素であり、システム間で重要な情報を安全に伝える役割を果たします。その信頼性を確保するために、JWTの検証は欠かせないステップです。一方、KongのようなAPIゲートウェイは、特にOAuth 2.0やOIDC標準が普及する中で、組織のAPIアーキテクチャにおいて重要な位置を占めています。 この記事では、KongでJWTを検証するためのツールを詳しく解説し、現代のWeb開発環境でこのプロセスが果たす役割を探ります。 JWTとは :::note すでにJWTについて理解している方は、どのプラグインを選ぶべきかの詳細を省略し、次のセクションから読み進めてください。 ::: JSON Web Token（JWT）は、JSON Web Signature（JWS）とJSON Web Encryption（JWE）の2つの形式で構成されています。本記事では、主にJWSの検証に焦点を当てています。JWEの検証について知りたい方は、こちらの記事をご覧ください。 RFC7515によると、JSON Web Signature（JWS）は、デジタル署名やメッセージ認証コード（MAC）で保護されたコンテンツを表現するためのJSONベースのデータ構造です。簡単に言えば、JWSは重要なメッセージを含む「署名付きの手紙」のようなものです。この手紙の信頼性を確保するためには、署名を検証する必要があります。 アルゴリズム JWSで使用される暗号アルゴリズムとその識別子は、別の仕様であるJSON Web Algorithms (JWA) JWAに定義されています。また、これらのアルゴリズムは、JWA仕様に基づいて作成されたIANAレジストリに記載されています。 JWSで使用される暗号アルゴリズムとその識別子は、別の仕様であるJSON Web Algorithms (JWA)仕様に記載されています。 通常、RS256やES256といった非対称アルゴリズムの使用が推奨されます。一方、HS256のような対称アルゴリズムの使用は推奨されていません。 JWTのデータ構造 まず、JWTの構造を見てみましょう。以下に例を示します。 eyJhbGciOiJFUzI1NiIsImtpZCI6Imh1SEE3RDVaTUNKTWhLaVJIZVgwaGZSWG9fX1VBbEpCZ0FkTjhxb0MwMXcifQ.eyJpc3MiOiAiZm9tbSIsICJhdWQiOiAiand0LWRlbW8iLCAic3ViIjogImRlbW8tdXNlciIsICJpYXQiOiAxNjcyNDAzMzc4LCAiZXhwIjogMTY3MjQwMzY3OH0.bxkLGEjN4pXQQ6eymBO_DYl24NGu07FFR1ZXgmdFYHPGsNX10r6iyqDEtCHeXWs7Hsn-QIasV_i4Lw2nCHmlAA``` JOSE header JOSEヘッダーには、通常、このJWSを保護するために使用されるハッシュアルゴリズム（alg）やキーID（kid）が記載されています。また、typ（タイプ）が含まれていることも一般的です 1 2 3 4 { "alg": "ES256", "kid": "huHA7D5ZMCJMhKiRHeX0hfRXo__UAlJBgAdN8qoC01w" } Payload ペイロードは、保護されて他の相手に渡されるメッセージです 1 2 3 4 5 6 7 { "iss": "fomm", "aud": "jwt-demo", "sub": "demo-user", "iat": 1672403378, "exp": 1672403678 } Signature ユーザーは、JOSEヘッダーで定義されたアルゴリズムを使用して、保護されたヘッダーとペイロードの署名を計算し、署名が一致することを確認する必要があります https://wenhan.blog/posts/20241206_kong_101_proxy_caching/ Fri, 06 Dec 2024 23:49:19 +0900 https://wenhan.blog/posts/20241206_kong_101_proxy_caching/ はじめに APIゲートウェイにおけるキャッシュの主な目的は以下の通りです： 高速なレスポンス バックエンドの負荷軽減 コスト削減 上段（リクエスト1回目）の流れ クライアントがKong Gatewayにリクエストを送信 Kong Gatewayはこのリクエストをバックエンド（上流のサービス）に転送 バックエンドからのレスポンスをKong Gatewayが受け取り、このレスポンスをキャッシュ（Response Cache）として保存 レスポンスをConsumer側に返す 下段（リクエスト2回目）の流れ クライアントが同じリクエストを送信 Kong Gatewayはキャッシュを確認し、保存されているレスポンスを直接回答 この場合、バックエンドにアクセスする必要がなくなるため、応答速度が大幅に向上 TTL（キャッシュの有効期限）が切れていない限り、このキャッシュが利用可能 Kongのキャッシュ機能は、プラグインで実現しています。プラグインを有効化し、必要な設定を加えるだけでキャッシュ機能を利用可能ですので簡単なセットアップができます。また、キャッシュの有効期間や対象データを細かく制御でき、ユースケースに応じた設定が可能です。さらに、キャッシュ自体を外に保存することができ、大規模なシステムでも効果的に動作し、Kongの高いスケーラビリティと連携します。 キャッシュの基本概念 キャッシュは、頻繁にアクセスされるデータを一時的に保存し、高速に提供する仕組みです。多くのキャッシュデータをRAM上に保存し、極めて高速なレスポンスを実現することができます。キャッシュには以下の3つの構成要素があります： キャッシュキー: 保存されたデータを特定するための識別子 キャッシュデータ: 保存される実際のレスポンスデータ TTL（Time-To-Live）: データの有効期限 Kong Gatewayで提供されるキャッシュ機能 Kongではキャッシュ機能を提供するプラグインは以下の二つがあります。 Proxy Caching Proxy Caching Advanced Proxy Caching Proxy Cachingプラグインは、HTTPレスポンスをキャッシュし、次回の同様のリクエストに対してキャッシュデータを直接返す仕組みです。これにより、バックエンドサービスへのアクセスを最小限に抑え、APIのパフォーマンスを向上させます。 まず、テスト用のServiceとRouteを作成します。 1 2 3 4 5 6 7 curl -i -X POST http://localhost:8001/services/ \ --data name=uuid_service \ --data url=http://httpbin.org/uuid curl -i -X POST http://localhost:8001/services/uuid_service/routes/ \ --data name=uuid_route \ --data paths=/uuid 次に、Serviceに対しProxy Cachingのプラグインを作成します。 https://wenhan.blog/posts/20241203_kong_101_ratelimiting/ Tue, 03 Dec 2024 23:49:19 +0900 https://wenhan.blog/posts/20241203_kong_101_ratelimiting/ 流量制限（Rate Limiting）の重要性 現代のAPI経済において、流量制限（Rate Limiting）は、システムの安定性、セキュリティ、そしてコスト効率の観点から非常に重要な役割を果たしています。以下にその重要性を詳細に解説します。 サーバーの負荷管理 APIは、予測不能な量のリクエストを受ける可能性があります。たとえば、突然の人気アプリケーションの登場や予期しないトラフィックの急増（いわゆる「スパイク」）によって、サーバーが過剰に負荷を受けることがあります。流量制限を設けることで、リクエストの最大許容量をコントロールし、サーバーが適切なパフォーマンスを維持できるようになります。 公平性の確保 流量制限は、すべてのユーザーが公平にAPIを利用できるようにするための重要な手段です。特定のユーザーやアプリケーションがリソースを独占することを防ぎ、他のユーザーの体験を守ります。 セキュリティの向上 悪意のあるリクエストやDoS（Denial of Service）攻撃、ボットによる不正アクセスなどに対抗する手段として、流量制限は有効です。異常なリクエストパターンを検知して制限することで、APIとシステム全体を守ることができます。 コスト管理 多くのクラウドプロバイダーやインフラサービスは、リクエスト数やデータ転送量に基づいて料金が発生します。無制限のリクエストを許可すると、予期しないコストが急増するリスクがあります。流量制限を設けることで、コストの予測がしやすくなり、無駄な支出を防ぎます。 Kongにおける流量制限の基本的な仕組み Kong Gatewayは、オープンソースで開発されたAPIゲートウェイで、APIの管理や保護を簡単に行うためのツールです。企業や開発者がAPIのセキュリティ、パフォーマンス、信頼性を向上させるために利用しています。Kong Gatewayでの流量制限（Rate Limiting）は、APIエンドポイントやごとのトラフィックを制御するための機能です。この機能は、プラグインとして提供されており、簡単に有効化して設定できます。 Kongの流量制限プラグインは、以下のように動作します： リクエストのカウント プラグインは、リクエストをカウントし、指定した時間枠（秒、分、時間、日など）内の許容範囲を超えると制限を適用します。 閾値の超過時の動作 許容範囲を超えたリクエストは、HTTPステータスコード（通常は429 Too Many Requests）とともに拒否されます。カスタムメッセージを設定することも可能です。 ストレージの活用 カウント情報を保持するために、ローカルメモリやRedisなどの外部ストレージを使用します。これにより、分散環境での一貫性を確保します。 柔軟な適用範囲 Service単位: 特定のAPIに制限を設定 Consumer単位: 個々のユーザーやアプリケーションごとに異なる制限を適用 Route単位: 特定のAPIエンドポイントのみに制限を設定 基本設定: Kongの流量制限プラグイン Kongの流量制限プラグインは、以下の二つがあります。どれもリクエスト数を時間単位で制限します。たとえば、1分間に3リクエストまで許可するなど、簡単に設定可能です。 [OSS] https://docs.konghq.com/hub/kong-inc/rate-limiting/ [Enterprise] https://docs.konghq.com/hub/kong-inc/rate-limiting-advanced/ Plugin設定 このブログでは、まずOSSの方から説明いたします。まず、テスト用のServiceとRouteを作成します。 1 2 3 4 5 6 7 curl -i -X POST http://localhost:8001/services/ \ --data name=uuid_service \ --data url=http://httpbin.org/uuid curl -i -X POST http://localhost:8001/services/uuid_service/routes/ \ --data name=uuid_route \ --data paths=/uuid 制限をかけていないため、無限にUUIDを生成することができます。 https://wenhan.blog/posts/20241201_kong_101_service_route/ Sun, 01 Dec 2024 23:49:19 +0900 https://wenhan.blog/posts/20241201_kong_101_service_route/ Kong Gatewayを活用する際に重要な役割を果たすのが「サービス (Service)」と「ルート (Route)」です。サービスがAPIリクエストの転送先を定義する一方で、ルートはそのサービスにリクエストをマッピングするルールを定めます。 サービスとは サービスは、Kong Gatewayがプロキシする外部APIやマイクロサービスの情報を定義したものです。具体的には、リクエストを転送する先のURL、ホスト名、ポート番号、プロトコルなどを設定します。 例えば、Kongを使ってバックエンドの「ユーザーAPI」をプロキシしたい場合、そのAPIをサービスとして登録します。このとき、Kongはクライアントからのリクエストを受け取り、そのリクエストを登録されたサービスに転送します。Kongにサービスを作成する際に設定する主な項目は以下の通りです： name: サービスの名前。識別のためのラベルとして機能します host: リクエストを転送する先のホスト名（例: example.com） port: 接続先のポート番号（デフォルト: 80または443） protocol: 使用するプロトコル（httpまたはhttps） path: 転送先の特定のパス（例: /api/v1/users） ルートとは サービスは単独では機能せず、「ルート (Route)」と連携して使用されます。ルートは、クライアントからのリクエストを特定のサービスにマッピングするための設定です。ルートでは以下のような条件を指定できます： パス (Path): クライアントがアクセスするURLのパス メソッド (Method): HTTPメソッド（例: GET, POST） ホスト名 (Host): リクエストのホストヘッダー ヘッダー (Header): 特定のHTTPヘッダー値 ルートの設定により、Kongはどのリクエストをどのサービスに転送するかを判断します。 実用例 1つのServiceと1つのRouteを構築 この例では、以下のように1つのServiceを一つのRouteで公開する方法を説明します。http://httpbin.org/uuid という外部APIをプロキシするサービスをKong Gatewayに登録し、それを/uuidというパスで公開します。公開されたエンドポイントにアクセスすると、UUID（ユニークな識別子）が取得できます。 まず、以下のコマンドを使用して、http://httpbin.org/uuidをターゲットとするサービスを作成します： 1 2 3 curl -i -X POST http://localhost:8001/services/ \ --data name=uuid_service \ --data url=http://httpbin.org/uuid このコマンドにより、以下の設定がKongに登録されます： サービス名: uuid_service 転送先URL: http://httpbin.org/uuid 次に、このサービスを公開するためのルートを作成します。以下のコマンドを使用して、/uuidというパスでこのサービスを公開します： 1 2 3 curl -i -X POST http://localhost:8001/services/uuid_service/routes/ \ --data name=uuid_route \ --data paths=/uuid このコマンドで登録されたルートには、以下の設定が含まれます： https://wenhan.blog/posts/20241029_konggw_rke2/ Tue, 29 Oct 2024 23:49:19 +0900 https://wenhan.blog/posts/20241029_konggw_rke2/ この記事は、Kong をRKE2上にインストールする手順をメモします。 RKE2のインストール RKE2 Server 1 2 3 4 5 6 7 8 9 10 root@ip-10-0-25-27:~# curl -sfL https://get.rke2.io | sh - [INFO] finding release for channel stable [INFO] using v1.30.5+rke2r1 as release [INFO] downloading checksums at https://github.com/rancher/rke2/releases/download/v1.30.5+rke2r1/sha256sum-amd64.txt [INFO] downloading tarball at https://github.com/rancher/rke2/releases/download/v1.30.5+rke2r1/rke2.linux-amd64.tar.gz [INFO] verifying tarball [INFO] unpacking tarball file to /usr/local root@ip-10-0-25-27:~# systemctl enable rke2-server.service --now Created symlink /etc/systemd/system/multi-user.target.wants/rke2-server.service → /usr/local/lib/systemd/system/rke2-server.service. root@ip-10-0-25-27:~# 後処理 1 2 3 4 5 6 7 # RKE2 Agentが利用するTokenファイル cat /var/lib/rancher/rke2/server/node-token # 同時にインストールされるkubectlのパス cp /var/lib/rancher/rke2/bin/kubectl /usr/local/bin/ # kubeconfigのファイルパス mkdir . https://wenhan.blog/posts/20241023_k3s_kong_mesh/ Wed, 23 Oct 2024 23:49:19 +0900 https://wenhan.blog/posts/20241023_k3s_kong_mesh/ Kong Meshは、サービスメッシュの管理を簡素化するためのプラットフォームで、マイクロサービス間の通信を安全かつ効率的に管理します。セキュリティ、可観測性、トラフィック制御といった機能を提供し、サイドカーアーキテクチャを利用して、各サービス間の通信をプロキシします。KubernetesやVMに対応し、異なる環境間でも統一したネットワーク管理を実現します。これにより、開発者はアプリケーションに集中でき、運用の複雑さを軽減できます。 この記事は、Kong Meshのデプロイ方法と、ポリシーの使い方をメモします。 K8s 環境の準備 標準のk8s環境であればどれでも大丈夫ですが、今回自分はk3sを使います。 1 2 export INSTALL_K3S_EXEC="--tls-san <ip address> --write-kubeconfig ~/.kube/config --write-kubeconfig-mode 644" curl -sfL https://get.k3s.io | sh - shの前に INSTALL_K3S_CHANNEL=v1.24.4+k3s1みたいのを入れればインストールするバージョンを指定できますが、省略する場合は最新のバージョンになります。 1 2 3 kubectl get node NAME STATUS ROLES AGE VERSION wenhan-demo Ready control-plane,master 5m56s v1.30.4+k3s1 Kong Meshのデプロイメント 今回はまずシンプルなSingle Zone構成をデプロイします。 Kumactl kumactlは、Kong MeshやKumaの管理用CLIツールで、サービスメッシュの設定やリソースの操作を簡単に行えます。CLIコマンドで、メッシュのデプロイ、ポリシー設定、監視が可能です。 以下の手順でkumactlを展開し、PATHにも追加します。 こちらも同じく、VERSIONを省略したら最新のバージョンがインストールされます。 1 2 3 4 curl -L https://docs.konghq.com/mesh/installer.sh | VERSION=2.8.2 sh - cd kong-mesh-2.8.2/bin export PATH=$(pwd):$PATH Kong Mesh Control Plane 以下のコマンドでKong Mesh Control Planeをk8s上にデプロイします。 ここで初めてkumactlを使います。インストールに必要なCRDなどが生成してくれます。 --license-pathには、Kong Gatewayと同じライセンスファイルのパスをセットします。 https://wenhan.blog/posts/20241008_terraform_deploy/ Tue, 08 Oct 2024 23:49:19 +0900 https://wenhan.blog/posts/20241008_terraform_deploy/ Terraformを使ったKonnect環境の構築 の記事がありまして、Terraformを使ってKonnect環境を設定する方法を書いています。 この記事では、Konnectではなく、On-prem環境のKong Gatewayに対する設定方法をメモとして残します。 今回使うterraformのプロバイダは以下になります。 https://github.com/Kong/terraform-provider-kong-gateway https://registry.terraform.io/providers/Kong/kong-gateway/latest/docs Kongやterraformのインストールなどは割愛 最低限に必要ファイル プロバイダーとKong GatewayのAdmin APIのアドレスの指定 1 2 3 4 5 6 7 8 9 10 11 terraform { required_providers { kong-gateway = { source = "kong/kong-gateway" } } } provider "kong-gateway" { server_url = "http://localhost:8001" } Serviceの定義 1 2 3 4 5 6 7 resource "kong-gateway_service" "httpbin" { name = "HTTPBin" protocol = "http" host = "httpbin.org" port = 80 path = "/" } Routeの定義、中に紐づいているServiceをIDで連携 1 2 3 4 5 6 7 8 9 10 11 resource "kong-gateway_route" "hello" { methods = ["GET"] name = "Anything" paths = ["/anything"] strip_path = false service = { id = kong-gateway_service. https://wenhan.blog/posts/20240919_konggw_ee_ecs/ Thu, 19 Sep 2024 23:49:19 +0900 https://wenhan.blog/posts/20240919_konggw_ee_ecs/ AWSのElastic Container Service (ECS)の概要 AWSのElastic Container Service (ECS)は、コンテナ化されたアプリケーションを簡単に実行、停止、管理できるフルマネージドコンテナオーケストレーションサービスです。ECSは以下の主な特徴を持っています： AWSのインフラストラクチャを活用した高可用性と拡張性 Dockerコンテナのサポート 他のAWSサービスとの統合 柔軟なスケジューリングオプション Kong Gatewayは、高性能なオープンソースAPIゲートウェイで、マイクロサービスの管理、セキュリティ、監視などの様々な機能を提供します。この記事では、Kong GatewayをECS環境にインストールする方法を説明します。インストールする全体像を以下に示します。 DBの準備 今回のデプロイでは、Postgre互換のAurora DBを利用しています。Aurora DBを作る時にデータベース名を指定することができるから、最初からKongに指定した方が楽です。 ecs-cliコマンドの準備 次にコマンドの準備です。アクセスの権限とクラスタの情報を事前に定義することができます。今回はFARGATEのタイプを作るため、default-launch-typeをFARGATEにしています。 1 2 3 4 5 6 7 8 9 10 11 12 > ecs-cli configure profile \ --profile-name kong-profile \ --access-key xxxxxxxx \ --secret-key xxxxxxxx INFO[0000] Saved ECS CLI profile configuration kong-profile. > ecs-cli configure \ --cluster kong-ecs \ --region ap-northeast-1 \ --config-name kong-config \ --default-launch-type FARGATE INFO[0000] Saved ECS CLI cluster configuration kong-config. https://wenhan.blog/posts/20240501_kong_gw_audit_log/ Wed, 01 May 2024 23:49:19 +0900 https://wenhan.blog/posts/20240501_kong_gw_audit_log/ 概要 KongのAudit Logは、Kongが行う各種操作を記録することで、システムの状態やセキュリティに関する洞察を提供します。これにより、システムの変更や問題のトラッキング、セキュリティ侵害の検出などが可能になります。 KongのAudit Logには、一般的にJSON形式で、次のような情報が記録されます。 リクエストやレスポンスのデータ ルートやサービスへのアクセス試行 ユーザーまたはクライアントの認証情報 APIキーの使用 エラーまたは警告メッセージ システムイベントや構成変更 https://docs.konghq.com/gateway/latest/kong-enterprise/audit-log/ 機能の有効化 Kong Audit logは、Enterpriseの機能です。デフォルトではOffであって、audit_logの変更で有効無効が設定できます。 1 2 audit_log = on ## audit logging is enabled audit_log = off ## audit logging is disabled 利用方法 例えば以下のようなアクセスがあった場合 1 curl -i -X GET http://localhost:8001/status このアクセスはAudit logに記録され、以下のリクエストで取得できます。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 $ curl -i -X GET http://localhost:8001/audit/requests HTTP/1. https://wenhan.blog/posts/20240404_deck_apiops_basic/ Thu, 04 Apr 2024 23:49:19 +0900 https://wenhan.blog/posts/20240404_deck_apiops_basic/ Deck CLI decKはAPIライフサイクル自動化（APIOps）のために開発されたコマンドラインツールである。これにより、開発者と運用チームは開発からデプロイまでAPIを管理し、API統合の一貫性、信頼性、スピードを確保できる。 decKコマンドは以下の機能と特徴を持っている。 エクスポート(バックアップ) 既存のKong構成をYAML形式の構成ファイルにエクスポートする インポート（リストア） エクスポートされた、または手書きの構成ファイルを使用して、Kong構成を反映する 差分と同期の機能 decKは、構成ファイル内の構成とKongのDB内の構成を比較し、それを同期することができます。これは、構成の差分を検出することも可能 逆同期 KongのDB内の構成があるのに、構成ファイルにない場合は、逆に構成ファイルへの同期もサポート 検証 構成ファイルの文法エラー検証 リセット Kongのデータベース内のすべてのエンティティを削除 並行操作 KongのAdmin APIへの呼び出しが並行して実行され、複数のスレッドを使用して同期プロセスを高速化 Kongとの認証 --headers Kong-Admin-Token:testの形でHTTPヘッダーに認証情報を入れて、認証必要なKongへのアクセスが可能 複数の構成ファイルでKongの構成を管理 エンティティ間で共有される一連のタグに基づいて、Kongの構成を複数のファイルに分割可能 構成管理の自動化 decKはCIパイプラインの一部として設計されており、Kongに構成をプッシュするだけでなく、構成のドリフトも検出可能 以下は、サブコマンド単位で例を載せる 事前準備 以下のKong構成ファイルをベースにしています。ServiceとRouteがひとつずつ存在する状態 1 2 3 4 5 6 7 8 9 10 11 _format_version: "3.0" services: - host: httpbin.org name: uuid-generator path: / protocol: http routes: - name: uuid-generator paths: - ~/uuid$ strip_path: false deck gateway 関連 deck gateway ping まずはpingで疎通確認 1 2 3 deck gateway ping --headers Kong-Admin-Token:test Successfully connected to Kong! https://wenhan.blog/posts/20240123_kong-oidc-plugin-extra-use-cases/ Tue, 23 Jan 2024 22:55:37 +0900 https://wenhan.blog/posts/20240123_kong-oidc-plugin-extra-use-cases/ (https://tech.aufomm.com/kong-oidc-plugin-extra-use-cases/ より翻訳) KongのOIDCプラグインはとてもパワフルで複雑なので（200近くのパラメーターがある…）、ユーザーがどのような設定の組み合わせが必要かを知っていれば、より多くのことができるようになる。今日の投稿では、このプラグインをよりうまく使うためのいくつかの使用例を紹介しよう。 なお、私はKong Gateway (Enterprise)の最新バージョン2.4.1.1を使用しています。 前提条件 Kong Gateway (Enterprise) OIDCサーバーが稼動していること。(私の例ではKeycloak) もしKeycloakの使い方がわからない場合は、以前の投稿をご覧ください IDPトークンからデータを抽出しヘッダへの追加 IDPトークンからアップストリームヘッダーに値をマッピングしたい場合は、config.upstream_headers_namesとconfig.upstream_headers_claimsを使用できます。 例えば、JWTトークンのペイロードに以下のようなclaimがあるとします。 1 2 3 4 5 { "payload": { "kong-test": "to-upstream" } } 目的は、ヘッダーkong-testにto-upstreamの値をマッピングし、アップストリームサーバーに送信することである。OIDCプラグインは以下のように設定できる。これはパスワードフローを使っている。 1 2 3 4 5 6 7 8 9 10 curl --request POST \ --url http://kong.li.lan:8001/plugins \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data name=openid-connect \ --data config.issuer=https://<keycloak>/auth/realms/demo \ --data config.client_id=<client_id> \ --data config.client_secret=<client_secret> \ --data config.auth_methods=password \ --data config.upstream_headers_claims=kong-test \ --data config.upstream_headers_names=test_kong ユーザー名とパスワードを指定してapiエンドポイントを呼び出すと、アップストリームサーバーに送信されるリクエストに以下のヘッダーが表示されるはずです。 https://wenhan.blog/posts/20230522_kong_jwt_plugin/ Mon, 22 May 2023 00:33:31 +0900 https://wenhan.blog/posts/20230522_kong_jwt_plugin/ (https://tech.aufomm.com/how-to-use-jwt-plugin/ より翻訳) Kongにはたくさんの認証プラグインがあります。今回はJWT Pluginの使い方についてお話したいと思います。 使用例 サービスを作成 1 2 3 4 curl -X POST http://localhost:8001/services \ -H "Content-Type: application/json" \ -H "Accept: application/json, */*" \ -d '{"name":"jwt-service","url":"https://httpbin.org/anything"}' Routeを作成 1 2 3 4 curl -X POST http://localhost:8001/services/jwt-service/routes \ -H "Content-Type: application/json" \ -H "Accept: application/json, */*" \ -d '{"name":"jwt-route","paths":["/jwt"]}' curl 'http://localhost:8000/jwt' -i でルートにアクセスすると、HTTP/1.1 200 OKとなるはずです。 JWT Pluginを有効 :::note このプラグインは、Service単位またはグローバル全体に有効化することも可能です。 ::: 1 2 3 4 curl --request POST \ --url http://localhost:8001/plugins \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data name=jwt 上記のルートをもう一度アクセスすると、HTTP/1. https://wenhan.blog/posts/20230308_using-sops-and-age-deploy-konggw/ Wed, 08 Mar 2023 16:41:18 +0900 https://wenhan.blog/posts/20230308_using-sops-and-age-deploy-konggw/ 背景 Kong Gatewayをデプロイする時に、データベースへの接続情報など平文で保存したくないデータが存在しています。これを解決するためにKong Secret Managerが開発され、AWS Secrets Managerなどの3rdパーティのサービスを利用すれば解決できます。しかし、環境によって外部のセキュリティサービスに接続できない時にこの機能は利用できません。ここで、Mozilaが開発したSOPSという暗号化ツールとGithub ActionのCI/CD workflowを利用し、普段暗号化されている設定ファイルをデプロイ時だけ復号し、Kong GWをインストールする実現することができました。 事前準備 CI/CD workflowを構築する前に、まずはローカル環境で暗号と復号を試してみましょう。以下の必要なツールをローカル環境にインストールします。 age sops SOPSはとても便利な暗号化・復号化のツールで人気があります。PGP, age, Google cloud’s KMS, Azure’s key valut, Hashicorp Vaultなどをサポートしています。今回は他のクラウドサービスを極力利用しない方針のため、ageを選択しました。 ツールのインストールができましたら、age-kengen --helpを試してみましょう。 1 2 3 4 5 6 7 8 $ age-keygen --help Usage: age-keygen [-o OUTPUT] age-keygen -y [-o OUTPUT] [INPUT] Options: -o, --output OUTPUT Write the result to the file at path OUTPUT. -y Convert an identity file to a recipients file. 見た感じ大丈夫そうなので、早速Keyを生成しましょう。 https://wenhan.blog/posts/20230223_vault_konggwdeploy_via_sm/ Thu, 23 Feb 2023 00:34:38 +0900 https://wenhan.blog/posts/20230223_vault_konggwdeploy_via_sm/ 背景 Kong Gateway 3.0 から、Secrets ManagementがGAとなりました。Kong Gateway は、データベースのパスワードからプラグインで使用される API キーまで、多くのSecretに依存して動作します。以前ではRBACを使って、Admin APIとKong Managerから機密情報へのアクセスを制限できましたが、Secretを平文で表示されずに管理できたら嬉しいですよね。これを実現できるのはSecrets Managementです。 サポートするVault 現時点で、サポートしているVaultは以下の４種類です。 AWS Secrets Manager GCP Secrets Manager HashiCorp Vault Environment Variable Kong は、上記の各システムを抽象化して、利用するときにVaultのキーワード(hcv、aws、gcpまたは env)を変更するだけで利用できます。たとえば、HashiCorp Vaultの Postgres Secretのpassword フィールドにアクセスするには、次のフォーマットで参照できます。 {vault://hcv/postgres/password} AWS Secrets Managerの場合 {vault://aws/postgres/password} 環境変数の場合 1 2 export POSTGRES='{"username":"user", "password":"pass"}' {vault://env/postgres/password} デモ では実際にSecrets Managementを使ってVaultのSecretsを参照し、Kongのデプロイを試してみよう Vault環境を用意 ここで、TOKEN_IDをkongにします。この値は後の認証するときに使用されます。 1 2 3 4 5 6 docker run -d --name vault.idp \ --network=kong-net \ -e "VAULT_DEV_ROOT_TOKEN_ID=kong" \ -p 8200:8200 \ --cap-add=IPC_LOCK \ vault:latest Secretを作成 コンテナーに入って、Secretを作成しましょう https://wenhan.blog/posts/20230220_exit_slack/ Mon, 20 Feb 2023 14:21:23 +0900 https://wenhan.blog/posts/20230220_exit_slack/ 背景 Kong Gatewayを使ってAPIにアクセスする時には、もしリクエストが失敗したら通知して欲しいですね。通常のやり方はLog系のプラグインでLogを保存してから、3rd partyの製品（ELK）でAlertを設定して通知することです。でも他の製品を使うとデプロイも面倒だし、ライセンスや設定内容も必要だし、できればKong内部で実現したいな。。という要望があると思います。 今回は、Exit Transformer プラグインを使って、リクエストがエラーだったらLuaスクリプトでSlack Webhookを叩くことをメモします。このプラグインは、Lua 関数を使用して、Kong 応答終了メッセージを変換およびカスタマイズすることができます。メッセージ、ステータスコード、ヘッダーの変更から、Kong 応答の構造の完全な変換まで、さまざまな機能があります。 プラグインを試す まずはページ上にある例を試してみよう。 サービスとルートを作成 1 2 http :8001/services name=example.com host=mockbin.org http -f :8001/services/example.com/routes hosts=example.com 失敗させるため key auth プラグインを実装 1 http :8001/services/example.com/plugins name=key-auth Luaスクリプトを作成 以下のコードでは、x-some-headerのヘッダーを追加し、メッセージの最後に, arrを追加した。 この内容をtransform.luaとして保存する。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 -- transform.lua return function(status, body, headers) if not body or not body.message then return status, body, headers end headers = { ["x-some-header"] = "some value" } local new_body = { error = true, status = status, message = body. https://wenhan.blog/posts/20230127_plugin_ordering/ Fri, 27 Jan 2023 11:42:28 +0900 https://wenhan.blog/posts/20230127_plugin_ordering/ Kong GatewayのPoCをやっている時に、ある問題に遭いました。 PoCの要件は以下になる Key-authプラグインでGateway全体を保護 Request-transformerプラグインで必要なAPI KeyをHeaderに付与し認証を突破 二つのプラグインを設定した後、API keyをrequestに追加されても認証されない 1 2 3 4 5 6 7 8 9 10 11 # key-auth is enabled ❯ http --header localhost:8000/demo | head -1 HTTP/1.1 401 Unauthorized # Got 401 after creating request-transformer-adv plugin. ❯ curl -X POST http://localhost:8001/services/testsvc/plugins \ --data "name=request-transformer-advanced" \ --data "config.add.headers=apikey:wenhandemo" ... ❯ http --header localhost:8000/demo | head -1 HTTP/1.1 401 Unauthorized 理由を調べたら、どうやらPluginのデフォルトの実行順番があるらしいです。 https://docs.konghq.com/gateway/latest/plugin-development/custom-logic/#plugins-execution-order key-authのプライオリティは1250、request-transformer-advの801より高いです。よってkey-authが実行するときに、Headerに必要なAPI Keyがまだ付与されていない状態になります。 解決方法として、Kong Gateway 3.0に新しく追加された機能、plugin orderingでプラグインの実行順番を明示すればOKです。 https://wenhan.blog/posts/20221122_event-hooks/ Tue, 22 Nov 2022 22:57:09 +0900 https://wenhan.blog/posts/20221122_event-hooks/ Event Hooks機能を利用することで、Kong Gatewayで特定のイベントが発生したときに通知を受け取ることができます。新しい管理者やサービスを作成したり、プラグインによる制限が有効になったりすることを監視したい場合に役に立ちます。 どのような機能? Event Hooksには以下の４種類があります。 webhook: 定義されたフォーマットのPOSTリクエストを送信 webhook-custom: カスタムしたHTTPリクエストを送信 log: Eventの内容をKong Gatewayのエラーログに記録 lambda: 事前に用意したLua関数を起動 ここでは、Webhook-customとlogを試していきます。 利用可能なEventを確認 Kong Gateway は adminAPIの/event-hooks/sources エンドポイントを提供します。ここから利用できるソース、Eventとパラメータを確認することができます。データが大量にあるので、一部抜粋で説明します。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 ... "rate-limiting-advanced": { "rate-limit-exceeded": { "fields": [ "consumer", "ip", "service", "rate", "limit", "window" ], "unique": [ "consumer", "ip", "service" ], "description": "Run an event when a rate limit has been exceeded" } }, . https://wenhan.blog/posts/20220906_gettingkongmanagertowork/ Wed, 07 Sep 2022 00:40:42 +0900 https://wenhan.blog/posts/20220906_gettingkongmanagertowork/ NOTE: https://svenwal.de/blog/20210316_kong_manager_install/ より翻訳 TL;DR: Kong Managerが動作しない場合は、KONG_ADMIN_API_URIとKONG_ADMIN_GUI_URLの設定を確認してください。 Kong Managerの紹介 2021年2月より、Kong Manager（長年Kong Enterpriseの機能でした）はKongの無料版の一部となりました。 私は長い間Kong Managerを使用しており、多くのユーザーが正しくセットアップするのを助けてきましたので、幾つの典型的な設定の問題を共有したいと思います。 Kong Managerは利用しやすい Kong Managerはout of the boxでありすぐに使えます。ローカル マシンに Kong (Free または Enterprise) をインストールし、有効にすると、 http://localhost:8002でKong Managerをすぐアクセスできます。 壊れ方 (直し方) 実際のインストールでは、Kong Managerを適当なローカルマシンに置くのではなく、サーバーにインストールし、適切なDNSエントリを使ってアクセスする必要があります。そして、そうしている間、8002のようなポートを持つのではなく、異なるホストネームを使用したいのです。 それでは、KongはLoadBalancer/Ingress/…の後ろにインストールされ、Kong Managerをhttps://kong-manager.my-company.example.comのような素敵なホスト名でを公開していると仮定しましょう。これを開くと、Kongマネージャが表示されますが、デフォルトのワークスペースは消えていて、新しいワークスペースを作成するボタンもありません。では、何が起こったのでしょうか？ KongのすべてがAPIであり、Kong Managerのユーザーインターフェイス全体が、ローカルのブラウザで動作するブラウザベースのアプリケーションであリます。そして、設定を変更していない場合、デフォルトのAdmin-APIアドレス（http://localhost:8001）への呼び出しが開始されます。 KongはAdmin-APIの外部URLを知ることができないため、設定でそれを指定する必要があります。例えば、8001-Portをhttps://kong-admin.my-company.example.com のようにマッピングしたとすると、次のように設定する必要があります。 1 admin_api_uri = https://kong-admin.my-company.example.com または（環境変数を使用している場合） 1 kong_admin_api_uri = https://kong-admin.my-company.example.com これで、ブラウザはAdmin APIがどこにあるかを知り、呼び出しを開始するようになりました。しかし、実際に試してみると、やはりうまくアクセスできません。では、何が足りないのでしょうか？ 私たちはKong ManagerとAdmin APIに異なるホスト名を作成しましたが、これはブラウザのCORS保護をトリガーします。https://kong-manager.my-company.example.com 上の JavaScript は https://kong-admin.my-company.example.com への呼び出しを試み、ブラウザはそれを拒否します（クロスオリジンのため）。そこで、第二段階として、Admin-API が正しい Allow-Origin-Header を送信しているかどうかを確認する必要があります。そのためには、Kong ManagerのURLがどのようなものであるかをKongに伝える必要があります。 1 admin_gui_url = https://kong-manager.my-company.example.com または（環境変数を使用している場合） 1 KONG_ADMIN_GUI_URL = https://kong-manager. https://wenhan.blog/posts/20220802_using-kong-gw-route-by-header-plugin/ Wed, 03 Aug 2022 01:19:02 +0900 https://wenhan.blog/posts/20220802_using-kong-gw-route-by-header-plugin/ 紹介 Kong GatewayではRouteでサブパスを定義し、どのServiceにアクセスするかを決めています。例えば、以下のURLの後ろのサブパスがpathAの場合は、トラフィックがserviceAにルーティングされ、最終的に後ろにあるendpointAにアクセスされます。 1 http://mykong.org:8000/pathA => serviceA => endpointA しかし、サブパスではなくて、もっと動的にリクエストの転送先を決めたい場合があります。このプラグインは、事前に定義されたヘッダーと転送先をルールに、リクエストヘッダ情報を見て転送先を決めています。ルールに二つのパラメータがあり、conditionは定義したヘッダーと値、upstream_nameは転送先のUpstreamオブジェクトです。 1 {"rules":[{"condition": {"location":"us-east"}, "upstream_name": "east.doamin.com"}]} この記事では、このプラグインの実装についてメモします。 注：このプラグインを操作できるのはAdmin APIを通す方法のみ。Kong Managerでの操作はできない。 https://docs.konghq.com/hub/kong-inc/route-by-header/ デモ 実際にこのプラグインを使ってみましょう。まずは作業用のserviceとrouteを作成する。serviceのendpointはhttp://httpbin.org/anything となりますが、このプラグインのルールに当てはまらない時にアクセスされます。 1 2 3 4 5 6 7 8 9 10 curl -i -X POST http://localhost:8001/services \ --data protocol=http \ --data host=httpbin.org \ --date path=/anything --data name=demo curl -i -X POST http://localhost:8001/routes \ --data "paths[]=/" \ --data service.id=<The id of service created above> --data name=demo 次に、転送先のUpstreamを二つ用意し、myipとdateをそれぞれアクセスするとIPアドレスと時間が表示されます。 1 2 3 4 5 curl -i -X POST http://localhost:8001/upstreams -d name=myip curl -i -X POST http://localhost:8001/upstreams/myip/targets --data target="ip. https://wenhan.blog/posts/20220531_using-kong-canary-release-plugin/ Tue, 31 May 2022 13:58:39 +0900 https://wenhan.blog/posts/20220531_using-kong-canary-release-plugin/ 紹介 Kong Gatewayのプラグインを利用すれば、カナリアリリースが簡単に設定することができます。しかもカナリアリリースのモードは単なるパーセンテージではなく、徐々に利用拡大や、Writelist&blacklistの設定もできます。 この記事では、カナリアリリースのやり方についてメモします。 https://docs.konghq.com/hub/kong-inc/canary/ ServiceとRouteの作成 デモの例として、現在のバージョンをhttp://httpbin.org/xmlに、新規リリースのバージョンをhttp://httpbin.org/jsonにします。なので、現在のバージョンの場合は、xmlのレスポンス、新規リリースのバージョンの場合は、jsonのレスポンスが帰ってくるはず。 1 2 3 4 5 6 7 ❯ http POST localhost:8001/services \ name=canary-api-service \ url=http://httpbin.org/xml ❯ http -f POST localhost:8001/services/canary-api-service/routes \ name=canary-api-route \ paths=/api/canary 動作確認、xmlのレスポンスが帰ってきた。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 ❯ http GET localhost:8000/api/canary HTTP/1. https://wenhan.blog/posts/20220517_using-kong-mocking-plugin/ Tue, 17 May 2022 13:58:39 +0900 https://wenhan.blog/posts/20220517_using-kong-mocking-plugin/ 紹介 Mockingプラグインは、開発中のAPIに対するテストを行うために、模擬のエンドポイントを提供するものです。Open API（OAS）仕様に基づいて、APIに送信されたリクエストに模擬応答をレスポンスします。また、テストの柔軟性のため、Mockingプラグインを簡単に有効または無効にすることができます。 https://docs.konghq.com/hub/kong-inc/mocking/ 注意点として、このプラグインは、200、201と204の応答をレスポンスすることができます。正常動作をテストするために開発されたもので、200番台以外のコードをを返すことができません。 今回は、db-less環境のKong-gatewayをDocker containerで構築し、その上に Mocking Pluginを試してみます。 Kong-gatewayをデプロイする前に db-lessの環境のため、Admin APIやGUIで設定を変更することはできません（保存先はないから）。そのため、起動時にDeclarative Configurationという名の設定ファイルを事前にコンテナーに食わせる必要があります。 https://docs.konghq.com/gateway/2.8.x/reference/db-less-and-declarative-config/#main 今回の目標は Mockingを試したいので、 Mockingの設定内容も事前にこのファイルに記述していきます。Mocking Pluginの紹介ページで書いたように、設定自体はとてもシンプルです。ただ、肝心なのはapi_specificationとapi_specification_filenameの二つです。この二つのパラメータは、模擬のエンドポイントのスペック内容を定義するために使われますが、違いは以下の通りです。 api_specification_filename: スペック内容が保存されたファイル名を設定する。 api_specification: スペック内容をそのままパラメータに設定する。 api_specification_filenameは、設定するファイルを事前にDev Portalにアップロードしてから、パスなしで設定してください。設定の例はここに書いています。しかし、今回はdb-lessの環境を構築するため、そもそもdev protalが利用できないし、api_specification_filenameを利用できません。 そのため、api_specificationにサンプルのAPIのスペック内容をそのまま設定し、コンテナーを立ち上げます。スペックのサンプルは、Mocking Pluginの紹介ページにあります。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 _format_version: "1.1" _transform: true services: - host: mockbin.org name: example_service port: 80 protocol: http routes: - name: example_route paths: - /mock strip_path: true plugins: - name: mocking config: api_specification: '{"swagger":"2. https://wenhan.blog/posts/20220303_access-k3s-from-outside/ Thu, 03 Mar 2022 23:49:19 +0900 https://wenhan.blog/posts/20220303_access-k3s-from-outside/ 外部からk3sクラスタへアクセスする デフォルト設定でk3sクラスタを作成した場合、そのノード内からしかアクセスできません。 /etc/rancher/k3s/k3s.yaml のkubeconfigファイルをノード外に持ち出して他のホストでインポートしようとすると、下記のようなエラーが発生します。 1 2 ❯ kubectl get node Unable to connect to the server: x509: certificate is valid for 10.0.140.68, 10.43.0.1, 127.0.0.1, not xxx.xxx.xxx.xxx ノード外からk3sクラスタにアクセスできるようにするには、クラスタ作成時に下記パラメータを指定します。 1 --tls-san value (listener) Add additional hostname or IP as a Subject Alternative Name in the TLS cert このパラメータの詳細は https://rancher.com/docs/k3s/latest/en/installation/install-options/#registration-options-for-the-k3s-server を参照してください。 インストールコマンド例は以下の通りです。 1 curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--tls-san <your node public ip address>" sh - その後、/etc/rancher/k3s/k3s.yaml の内容をローカルマシンにコピーし、serverのIPアドレスを 127.0.0.1 から実際にアクセスしたいアドレスに書き換えます。 これでクラスタ情報の取得ができ、問題なくアクセスできるようになります。 1 2 3 ❯ kubectl get node NAME STATUS ROLES AGE VERSION wenhan-dev Ready control-plane,master 61s v1. https://wenhan.blog/posts/20220126_--node-cidr-mask-size_error/ Wed, 26 Jan 2022 11:33:00 +0900 https://wenhan.blog/posts/20220126_--node-cidr-mask-size_error/ rkeクラスタのcidrを弄ったら、以下のようなエラーが出てクラスタの作成が失敗した。 1 {"log":"F1203 01:36:22.168496 1 node_ipam_controller.go:115] Controller: Invalid --cluster-cidr, mask size of cluster CIDR must be less than or equal to --node-cidr-mask-size configured for CIDR family\n","stream":"stderr","time":"2021-12-03T01:36:22.16859524Z"} cluster.yamlの関連部分は以下のようになっています。 1 2 3 4 5 6 services: kube-controller: cluster_cidr: 10.42.0.0/25 service_cluster_ip_range: 10.43.0.0/25 kube-api: service_cluster_ip_range: 10.43.0.0/25 問題になる場所はCIDRのマスクサイズです。このマスクサイズは--node-cidr-mask-sizeで設定され、クラスタのCIDRのマスクサイズより大きく（IP範囲が少なく）なる必要があります。デフォルトは24のため、上記の設定の25より小さい（IP範囲が溢れた）のでエラーとなりました。 この--node-cidr-mask-sizeは、以下のようにextra_argsで変更することができます。 1 2 3 4 5 6 services: kube-controller: cluster_cidr: 10.42.0.0/25 service_cluster_ip_range: 10.43.0.0/25 extra_args: node-cidr-mask-size: 25 25, 26のような数字に設定したら、クラスタの作成ができるようになります。 このマスクサイズとノードあたりで利用できるPod数の関係として、Pod の追加 / 削除などを考慮し、確保したIPアドレスの数の半分ぐらいが実際に作成できるPodの数となります。 例えば、cluster_cidrのマスクが25なので、クラスタレベルのIPアドレス数は128個です。 1ノードの場合、--node-cidr-mask-sizeを同じく25を設定したら128個のIPアドレスが確保され、33～64のPodが作成できます。 3ノードの場合、ノードあたりのIP数は42個までしか使えなくて、--node-cidr-mask-sizeを27に設定しなければいけません。そうすると、Pod数は 9～16になります。 システムレベルのPod（corednsなど）も10個程度あるので、28にしたら業務Pod用のIPアドレスが足りなくなります。 https://wenhan.blog/posts/20211111_fleet-demo/ Thu, 11 Nov 2021 16:18:38 +0900 https://wenhan.blog/posts/20211111_fleet-demo/ この記事では、Single nodeのRancher server と二つのk3sクラスタ環境を構築し、 そRancherのContinuous Delivery機能で、二つのk3sクラスタをGitOpsで操作します。 Step 1: Deploying a Rancher Server まずはrancherノードで、以下のdocker コマンドを実行しSingle nodeのRancher serverを構築します。 1 2 3 4 sudo docker run -d --restart=unless-stopped \ -p 80:80 -p 443:443 \ --privileged \ rancher/rancher:v2.5.10 Rancher serverが1分程度で立ち上がりますので、rancherノードのIPアドレスをブラウザで開いてRancher UIをアクセスしてください。 今回の場合、Rancherは自己署名証明書を使用しているため、ブラウザに証明書の警告が表示されます。この警告はスキップしても問題ありません。 また、一部のブラウザでは、スキップボタンが表示されない場合があります。 この場合は、エラーページの任意の場所をクリックして、thisisunsafeと入力します。 これにより、ブラウザは警告をバイパスして証明書を受け入れるようになります。 初回アクセスの時パスワードの初期設定が必要です。画面のガイドに従って設定してください。 Step 2: Deploy k3s Kubernetes Cluster 次はk3sクラスタをデプロイします。手順はとても簡単で、以下のコマンドをk3s-1とk3s-2ノードで実行するだけです。 後でアップグレードもやる予定なので、ここではあえてちょっと古いバージョンを指定しk3sのクラスタをデプロイします。 k3s-1 1 sudo curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=v1.19.15+k3s2 sh - k3s-2 1 sudo curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION=v1.19.15+k3s2 sh - デプロイが完了したら、以下のコマンドでクラスタを確認してください。 https://wenhan.blog/posts/20210623_modify-kubeadm-cert-expired-period-test/ Wed, 23 Jun 2021 17:34:31 +0900 https://wenhan.blog/posts/20210623_modify-kubeadm-cert-expired-period-test/ 業務の都合で、有効期限切れのKubernetesクラスタで証明書の更新手順を検証する必要がありました。 初めての作業だったので、ここに手順を記録します。 kubeadmソースの修正とビルド ビルド環境にgoとgitをインストールし、goのバイナリパスをPATHに追加します。 Kubernetesのソースコードをダウンロードします。今回はv1.18.18を使用しました。 git clone -b v1.18.18 https://github.com/kubernetes/kubernetes 証明書の有効期間を10分に設定するため、以下のファイルを修正します： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 diff --git a/cmd/kubeadm/app/constants/constants.go b/cmd/kubeadm/app/constants/constants.go index b56891ca908..eed934280e7 100644 --- a/cmd/kubeadm/app/constants/constants.go +++ b/cmd/kubeadm/app/constants/constants.go @@ -46,7 +46,8 @@ const ( TempDirForKubeadm = "tmp" // CertificateValidity defines the validity for all the signed certificates generated by kubeadm - CertificateValidity = time. https://wenhan.blog/posts/20200609_rancher-learning-from-zero/ Tue, 09 Jun 2020 16:12:08 +0900 https://wenhan.blog/posts/20200609_rancher-learning-from-zero/ 紹介 Rancherはrancher-server とrancher-agent、そして一つ以上のkubernetes clusterによって構成されている。この中、rancher-agentは管理されたkubernetesに実行され、rancher-serverと通信し、クラスタの情報を送信する。 rancher-serverはkubernetesを管理するためのWebUIとAPIを提供している。rancher-serverはHTTPSのみアクセスできる。 インストール シングルノード シングルノードの構築は以下二つの方法があります。 dockerで直接rancher-serverを実行 rkeで一つのノードに全てのroleを有効 rkeの方法は後でも出てくるので割愛、ここではdockerの方法を示す。 rancher-serverを実行したいノードで、下記のコマンドを入力する。 1 2 3 docker run -d --restart=unless-stopped \ -p 80:80 -p 443:443 \ rancher/rancher:latest これでシングルノードのrancher-serverを起動した。http://<IP Address>でアクセスできる。 マルチノード rkeを使ってHA環境のrancher-serverを構築する。 rke(rancher k8s engine)はkubernetesを構築するためのコマンドで、環境を用意すればコマンド一つでクラスターを構築できる。 マシンの用意 今回はmultipass でマシンを準備する。以下のコマンドで６台の仮想マシンを作成する。 1 2 3 4 5 6 multipass launch -c 2 -m 4096M -d 20G --cloud-init=./cloud-init.yaml -n kmaster1 multipass launch -c 2 -m 4096M -d 20G --cloud-init=./cloud-init.yaml -n kmaster2 multipass launch -c 2 -m 4096M -d 20G --cloud-init=. https://wenhan.blog/posts/20200405_self-nas-environment-project/ Sun, 05 Apr 2020 15:22:58 +0900 https://wenhan.blog/posts/20200405_self-nas-environment-project/ この投稿は、Ubuntu 20.04を使ってプライベートNASステーションを構築するための自分用メモです。NASの主な用途は写真の保存です。 その他のサービスとして、WebUIでマシンを管理するためにwebminを、マルチメディア用にEmby/Jellyfinを動かします。これら2つはdocker上で動かすので、管理用にportainerも導入します。 概要 ストレージ共有にはSambaを使い、iPhoneからNASへ写真をアップロードするにはPhotoSyncを利用します。ディスクの状態確認にはsmartctlを使い、異常があればメールで通知します。 ファイル共有（Samba） Sambaのインストールは以下の通り： 1 sudo apt-get install samba smbfs 設定ファイル/etc/samba/smb.confを開いて設定します。 必要に応じてワークグループを変更してください。 1 2 # Change this to the workgroup/NT-domain name your Samba server will part of workgroup = WORKGROUP 次に共有フォルダを設定します。ファイルの末尾に以下を追加してください。 1 2 3 4 5 6 7 [share] comment = Share directory for my self-nas path = /share read only = no guest only = no guest ok = no share modes = yes smbdサービスを再起動し、正常に動作しているか確認します。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 wshi@nuc:~$ sudo systemctl restart smbd wshi@nuc:~$ sudo systemctl status smbd ● smbd. https://wenhan.blog/posts/20200331_multipass-launch-failed-by-network-timeout/ Tue, 31 Mar 2020 10:04:31 +0900 https://wenhan.blog/posts/20200331_multipass-launch-failed-by-network-timeout/ MultipassはUbuntuのVMインスタンスを作成するのに非常に便利なツールです。 CLIでLinuxインスタンスの起動や管理ができ、クラウドイメージのダウンロードも自動で行われ、数分でVMを立ち上げることができます。 https://multipass.run/ しかし、私の場合、multipass 1.1.0でインスタンスをクイック起動しようとしたところ、Network timeout エラーで失敗しました。 1 2 3 4 5 6 $ multipass version multipass 1.1.0 multipassd 1.1.0 $ multipass launch launch failed: failed to download from 'http://cloud-images.ubuntu.com/releases/server/releases/bionic/release-20200317/ubuntu-18.04-server-cloudimg-amd64.img': Network timeout このリンクを wget で確認したところ問題なかったので、イメージのダウンロード時間がmultipassのタイムアウト値を超えているのではと推測しました。 手動でダウンロードして、そのイメージを使ってインスタンスを起動できるか？もちろん可能です。 イメージをダウンロードし、そのパスをパラメータとして渡せばOKです。 1 2 $ multipass launch file:///home/wshi/Downloads/ubuntu-18.04-server-cloudimg-amd64.img Launched: lucrative-eelpout 日本でのダウンロード時間についてもう1点。 http://cloud-images.ubuntu.com は私の環境では遅かったので、富山大学のミラー http://ubuntutym2.u-toyama.ac.jp/cloud-images/releases/ を利用しました。 オリジナルより10倍速く、参考になれば幸いです。 https://wenhan.blog/posts/20200330_moving-from-hexo-to-hugo/ Mon, 30 Mar 2020 14:07:21 +0900 https://wenhan.blog/posts/20200330_moving-from-hexo-to-hugo/ HexoからHugoに 今までHexoでブログを書いたが、Golang勉強のついでにHugoに移しました。 理由はいろいろありますが、主な点は以下 Hexoは複数のモジュールを使うので、たまにインストールがコケる それに対しHugoはバイナリ一つで十分 HTMLファイル生成のスピード、HexoよりHugoが断然に速い Hugoのインストール方法や利用方法については割愛しましたが、今回のブログ移転で 実際に会った問題を整理する Tagの付け方 Hexoの場合、以下のタグの付け方が大丈夫でしたが、Hugoの時はだめでした 1 tag: Python 全部以下に統一すれば問題ない 1 2 tags: - Python Blog mdファイルの保存場所 これはthemeによって異なります。今回はEvenを利用したのでpostになっています。 生成したブログページとGithub Actionの連携 Hexoの場合、deployのサブコマンドでGithubにPush出来ましたが、Hugoの場合はでき ません。Hugo deployコマンドは一応ありますが、AWS,GCE,Azure向けでした。 https://gohugo.io/hosting-and-deployment/hugo-deploy/ そのためファイルを生成して手動でgithub pageのレポジトリーにpushする必要がありま す。生成したブログページのファイルがpublicディレクトリにあります。 Github Actionを利用すれば、新しい記事を書いてpushしたら、上記の処理が全自動に 出来ます。そのやり方は次の記事に纏めます。 httpsの対応 Hugoと関係ないが、ついでにCloudFlareを使ってhttpsへ対応した。 https://wenhan.blog/posts/20191001_asrock-fatal1ty-b450-gaming-itx-restore-on-ac-power-loss-not-working/ Tue, 01 Oct 2019 13:13:11 +0000 https://wenhan.blog/posts/20191001_asrock-fatal1ty-b450-gaming-itx-restore-on-ac-power-loss-not-working/ ASRock Fatal1ty B450 Gaming-ITX（BIOS 3.40）を使っています。 リモートで電源を入れたいため、BIOS設定で「Restore on AC/Power Loss（AC/電源復旧時に復元）」を有効にしましたが、うまく動作しませんでした。 調べてみたところ、下記の情報を見つけ、BIOSファームウェアを3.53にアップデートしたら、正常に動作するようになりました！ v3.53は下記リンクから入手できます。 http://forum.asrock.com/forum_posts.asp?TID=12059&title=fatal1ty-b450-gamingitx-restore-on-ac-power-loss https://wenhan.blog/posts/20190817_access-wifi-point-via-command-line-cli/ Sat, 17 Aug 2019 00:55:53 +0000 https://wenhan.blog/posts/20190817_access-wifi-point-via-command-line-cli/ この作業には nmcli を使います。 まず network-manager パッケージをインストールし、デーモンを起動します。 1 2 sudo apt install network-manager sudo systemctl start NetworkManager 次に、以下のコマンドでネットワークインターフェースの状態を確認します。 1 2 3 4 5 6 7 $ nmcli dev status DEVICE TYPE STATE CONNECTION wlp2s0 wifi connected xibuka-wifi-5G enp0s31f6 ethernet connected netplan-enp0s31f6 p2p-dev-wlp2s0 wifi-p2p disconnected -- eth0 ethernet unavailable -- lo loopback unmanaged -- 次に、利用可能なWi-Fiアクセスポイントを確認します。 1 2 3 4 5 6 7 8 9 10 $ nmcli dev wifi list SSID MODE CHAN RATE SIGNAL BARS SECURITY aterm-55ebc5-g Infra 11 405 Mbit/s 77 ▂▄▆_ WPA1 WPA2 xibuka-wifi-2G Infra 11 405 Mbit/s 77 ▂▄▆_ WPA1 WPA2 xibuka-wifi-5G Infra 36 405 Mbit/s 63 ▂▄▆_ WPA1 WPA2 aterm-55ebc5-a Infra 36 405 Mbit/s 54 ▂▄__ WPA1 WPA2 HG8045-0D9B-bg Infra 8 195 Mbit/s 49 ▂▄__ WPA1 WPA2 HG8045-0D9B-a Infra 44 405 Mbit/s 35 ▂▄__ WPA1 WPA2 HG8045-A39A-a Infra 108 405 Mbit/s 35 ▂▄__ WPA1 WPA2 MNG6300-F560-G Infra 11 130 Mbit/s 30 ▂___ WPA1 WPA2 目的のSSIDが表示されない場合は、以下のコマンドで再スキャンできます。 https://wenhan.blog/posts/20190625_bash-head-options/ Tue, 25 Jun 2019 00:12:59 +0000 https://wenhan.blog/posts/20190625_bash-head-options/ コマンドが失敗した時に即座にスクリプトを終了する 1 2 set -o errexit set -e 未定義変数を参照した時にエラーを出力して即座にスクリプトを終了する 1 2 set -o nounset set -u パイプ内のコマンドが失敗してもスクリプトを終了する 1 set -o pipefail https://wenhan.blog/posts/20181207_presentasion-about-microk8s-at-containerdaystokyo/ Fri, 07 Dec 2018 00:33:49 +0000 https://wenhan.blog/posts/20181207_presentasion-about-microk8s-at-containerdaystokyo/ ContainerDays Tokyoでmicrok8sとsnapについて発表しました。 スライド（日本語）は以下からご覧いただけます。 speakerdeck.com お楽しみください！ https://wenhan.blog/posts/20180927_openstack-frequently-used-command/ Thu, 27 Sep 2018 22:09:02 +0000 https://wenhan.blog/posts/20180927_openstack-frequently-used-command/ OpenStackでよく使うコマンド OpenStack Compute - Nova インスタンス一覧 nova list openstack server list フレーバー一覧・確認 nova flavor-list nova flavor-show <name or ID> openstack flavor list openstack flavor show <name or ID> フレーバー作成 openstack flavor create --ram <ram> --vcpus <cpu number> --disk <size> --id <id> <name> nova flavor-create <name> <id> <ram> <disk> <vcpus> インスタンス起動 nova boot <name> --image <image> --flavor <flavor> openstack server create --flavor <flavor> --image <image> <name> ネットワーク指定でインスタンス起動 openstack server create --flavor <flavor> --image <image> <name> net-id=<network> キーペア指定でインスタンス起動 nova boot <name> --image <image> --flavor <flavor> --key-name <key-pair name> openstack server create --flavor <flavor> --image <image> <name> ルーター経由でインスタンスにアクセス ip netns list sudo ip netns exec <qrouter-id> ssh -i <key> user@ip カスタムポートでインスタンス起動 nova boot --image <image> --flavor <flavor> --nic port-id=<port-id> <instance name> インスタンス削除 nova delete <ID> openstack server delete <ID or name> Openstack Network - Neutron ネットワーク一覧 openstack network list サブネット一覧 openstack subnet list --long ネットワーク作成 openstack network create <net name> サブネット作成 openstack subnet create <subnet name> --network <net name> --subnet-range <ip address>/<prefix> --gateway <gw ip> --allocation-pool start=IP_ADDR,end=IP_ADDR 例： openstack subnet create practicesubnet --network practice --subnet-range 10. https://wenhan.blog/posts/20180829_certified-kubernetes-administrator-cka-learning-note/ Wed, 29 Aug 2018 11:40:56 +0000 https://wenhan.blog/posts/20180829_certified-kubernetes-administrator-cka-learning-note/ インストール docker.io のインストール 1 apt install docker.io 他の cgroup driver で docker をインストールした場合は、docker と Kubernetes が同じ cgroup driver を使うように設定する必要があります。 1 2 3 4 5 cat << EOF >> /etc/docker/daemon.json { "exec-opts": ["native.cgroupdriver=systemd"] } EOF apt キーとソースをシステムに追加 1 2 3 4 5 root@kube-master:~# curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - OK root@kube-master:~# cat <<EOF >> /etc/apt/sources.list.d/kubernetes.list > deb http://apt.kubernetes.io/ kubernetes-xenial main > EOF その後、kubernetes パッケージをインストールします。 1 2 root@kube-master:~# apt update -y root@kube-master:~# apt install -y kubelet kubeadm kubectl kubeadm でセットアップと設定 kubeadm init を実行する際、CNI を選択する必要があります。ここでは flannel を選ぶので、--pod-network-cidr オプションを追加します。 https://wenhan.blog/posts/20180628_juju-use-juju-to-deploy-minecraft-server-in-lxd/ Thu, 28 Jun 2018 17:01:36 +0000 https://wenhan.blog/posts/20180628_juju-use-juju-to-deploy-minecraft-server-in-lxd/ JujuはAWS、Azure、Google Cloud Platform、MAAS、LXDなど、非常に多くのクラウドプロバイダーに対応したデプロイツールです。 この記事では、JujuとLXDを使ってOpenStackのテスト環境を構築する方法に焦点を当てます。 LXDのインストール LXDのインストールはとても簡単で、以下のコマンドを実行するだけです。 1 sudo apt-install lxd lxdパッケージが見つからない場合は、以下のコマンドでPPA（Personal Package Archive）を追加し、再度インストールコマンドを実行してください。 1 2 3 sudo apt-add-repository ppa:ubuntu-lxc/stable sudo apt update sudo apt dist-upgrade LXDの設定 以下のコマンドを実行して、LXDの設定をステップバイステップで行います。 1 2 3 4 5 6 7 8 $ sudo lxd init Do you want to configure a new storage pool (yes/no) [default=yes]? Name of the storage backend to use (dir or zfs) [default=dir]: Would you like LXD to be available over the network (yes/no) [default=no]? https://wenhan.blog/posts/20180611_suspend-issue-on-thinkpad-x1c-6th-with-ubuntu-18-04/ Mon, 11 Jun 2018 15:38:10 +0000 https://wenhan.blog/posts/20180611_suspend-issue-on-thinkpad-x1c-6th-with-ubuntu-18-04/ デフォルトでS3サスペンドがサポートされていない Ubuntu 18.04を使用していると、Thinkpad X1 Carbonでサスペンドに問題が発生します。蓋を閉じても正しくサスペンドされず、電力消費が続き、ノートPCが熱くなります。 原因は、第6世代X1 CarbonがS0i3（Windows Modern Standbyとしても知られる）をサポートしている一方で、S3スリープ状態をサポートしていないことです。 S0i3スリープのサポート 調査の結果、以下の手順で回避策が見つかりました： カーネルパラメータに以下を追加してS0i3スリープを有効化 これにより、蓋の開閉によるウェイクアップ/レジュームが無効化されます。 1 acpi.ec_no_wakeup=1 BIOS設定でThunderbolt BIOS Assist Modeを有効化 Config -> Thunderbolt BIOS Assist Mode - "Enabled" に設定します。 SDカードリーダーを無効化 この問題の詳細は以下を参照してください： X1 Carbon Gen 6 cannot enter deep sleep (S3 state aka Suspend-to-RAM) on Linux Suspend issues X1 Carbon 6th gen S0i3 sleep broken この回避策は後日テストし、結果を更新します。 もう一つの回避策がhttps://delta-xi.net/#056にありますが、こちらは未検証です。 テスト結果 8時間以上スリープさせたところ、バッテリーは99%から91%までしか減らず、温度も低いままでした。この回避策は有効だと思います。 https://wenhan.blog/posts/20180604_error-failed-container-creation-failed-to-load-raw-lxc/ Mon, 04 Jun 2018 16:19:39 +0000 https://wenhan.blog/posts/20180604_error-failed-container-creation-failed-to-load-raw-lxc/ 以下のURLを参考にMaaSのインストールとテストを試みました。 https://docs.maas.io/2.1/en/installconfig-lxd-install 上記ドキュメントのプロファイル編集部分より lxc profile edit maas configの後ろの{}を以下の内容（config:は除く）に置き換えます： 1 2 3 4 5 6 config: raw.lxc: |- lxc.cgroup.devices.allow = c 10:237 rwm lxc.aa_profile = unconfined lxc.cgroup.devices.allow = b 7:* rwm security.privileged: "true" launch手順で以下のエラーが発生しました： 1 2 3 $ lxc launch -p maas ubuntu:16.04 xenial-maas Creating xenial-maas Error: Failed container creation: Failed to load raw.lxc これは自分がLXD 3.0を使っているためで、上記の設定キーが古いことが原因です。 このコメントによると、lxd 2.1以降はlxc.aa_profileがlxc.apparmor.profileに変更されています。 したがって、回避策は以下の通りです。 再度 lxc profile edit maas lxc.aa_profile を lxc.apparmor.profile に置き換えます。 1 2 3 4 5 6 config: raw. https://wenhan.blog/posts/getting-started-with-ansible-jp-basic/ Mon, 09 Apr 2018 15:25:32 +0000 https://wenhan.blog/posts/getting-started-with-ansible-jp-basic/ こちらの記事はではAnsibleを紹介するための文章で、元Red Hat社員のJingjing Shiが作成し、Wenhan Shiが日本語に翻訳しました。内容の校正はHideki SaitoとKento Yagisawaが協力しています。Ansibleの基礎知識から、実際の現場で利用できる実運用まで紹介しています。 本文内にあるすべてのansible playbookの例は、以下のgithubのURLから利用できる。 https://github.com/ansible-book/ansible-first-book-examples もし不備やコメントがありましたら、作者shijingjing02@163.comまたは翻訳者shibunkan@gmail.com に連絡してください。 詳細の内容を下記三つに分けて説明します。 Ansible 入門 - 紹介 Ansible 入門 - 基本 Ansible 入門 - 応用 本章では、簡単な例を使ってAnsibleの基本的な使い方を説明する。 インストール 管理対象のサーバー（サーバリストの管理） コマンドラインによるサーバー管理(Ad-hoc command) スクリプトによるサーバー管理(スクリプト言語 Playbook) モジュール インストール ここでは Red Hat 系 Linux でのインストールを前提に解説にする。他のOSに関していAnsibleのWebページをご参照ください。 管理者ノード Ansible パッケージをインストール 1 2 3 4 # Redhat/CentOS Linuxの場合, epolリポジトリをインストールする必要がある。 # Fedoraの場合、デフォルトのリポジトリにAnsibleを含まれているため，直接インストールできる sudo yum install epel-release sudo yum install ansible -y 管理者ノードからリモートノードの接続設定 SSH keyによる認証パスワードレス）方式を設定する。 1 2 3 4 5 6 # ssh key を生成 ssh-keygen # リモートノードにssh keyをコピー ssh-copy-id remoteuser@remoteserver # リモートノードをknows_hostsに追加（ssh Keyの保存確認がなくなる） ssh-keyscan remote_servers >> ~/. https://wenhan.blog/posts/getting-started-with-ansible-jp-adv/ Mon, 09 Apr 2018 15:20:32 +0000 https://wenhan.blog/posts/getting-started-with-ansible-jp-adv/ こちらの記事はではAnsibleを紹介するための文章で、元Red Hat社員のJingjing Shiが作成し、Wenhan Shiが日本語に翻訳しました。内容の校正はHideki SaitoとKento Yagisawaが協力しています。Ansibleの基礎知識から、実際の現場で利用できる実運用まで紹介しています。 本文内にあるすべてのansible playbookの例は、以下のgithubのURLから利用できる。 https://github.com/ansible-book/ansible-first-book-examples もし不備やコメントがありましたら、作者shijingjing02@163.comまたは翻訳者shibunkan@gmail.com に連絡してください。 詳細の内容を下記三つに分けて説明します。 Ansible 入門 - 紹介 Ansible 入門 - 基本 Ansible 入門 - 応用 本章では、もっと自由に運用するために、Ansibleの高度な使い方を説明する。 Ansibleの設定ファイル サーバーリスト管理（Host Inventory） Playbookの上級な書き方 Extraモジュールの利用 Ansible設定ファイル 設定内容 基本の設定内容 項目 詳細 内容（デフォルト） inventory リモートノードリスト管理ファイル /etc/ansible/hosts library 拡張モジュールフォルダ /usr/share/my_modules/ remote_tmp リモートノード上のファイル一時保存場所 $HOME/.ansible/tmp local_tmp 管理者ノード上のファイル一時保存場所 $HOME/.ansible/tmp 高度の設定内容 項目 詳細 内容（デフォルト） accelerate_port 接続ポート番号 5099 accelerate_timeout タイムアウト 30 accelerate_connect_timeout 接続タイムアウト 5 上記は設定できる内容の一部しかすぎない。以下のAnsible設定ファイルの全体を通して、どんなことができるのはは理解できる https://raw.githubusercontent.com/ansible/ansible/devel/examples/ansible.cfg 設定ファイル内のキーワードについて不明な点があった場合、下記のURLから詳細を参照できる。 http://docs.ansible.com/ansible/intro_configuration.html#explanation-of-values-by-section 優先順位 設定ファイルのデフォルトのパスは/etc/ansible/ansible.cfg。Ansibleは以下の順番で設定ファイルを検索し、最初に見つけたファイルの設定内容を読み込む。 ANSIBLE_CONFIG (an environment variable) ansible. https://wenhan.blog/posts/getting-started-with-ansible-jp-intro/ Mon, 09 Apr 2018 15:15:32 +0000 https://wenhan.blog/posts/getting-started-with-ansible-jp-intro/ こちらの記事はではAnsibleを紹介するための文章で、元Red Hat社員のJingjing Shiが作成し、Wenhan Shiが日本語に翻訳しました。内容の校正はHideki SaitoとKento Yagisawaが協力しています。Ansibleの基礎知識から、実際の現場で利用できる実運用まで紹介しています。 本文内にあるすべてのansible playbookの例は、以下のgithubのURLから利用できる。 https://github.com/ansible-book/ansible-first-book-examples もし不備やコメントがありましたら、作者shijingjing02@163.comまたは翻訳者shibunkan@gmail.com に連絡してください。 詳細の内容を下記三つに分けて説明します。 Ansible 入門 - 紹介 Ansible 入門 - 基本 Ansible 入門 - 応用 本章では、Ansibleの基礎部分の紹介を説明する。 Ansibleとは Ansibleとはなにか？ Ansibleは、複数のサーバを一括でコントロールする構成管理ツールである。コントロールできるサーバ対象はリモートの仮想マシンでも物理マシンでも問ローカルのサーバマシンも問題ない。 Ansibleでなにができる？ Ansibleでは、SSHなどを利用し管理ノードからリモートノードへの通信を行う。理論上では、サーバ管理者がsshでサーバにログインした後できるすべてのことに対し、Ansibleも同じことができる。 例えば ファイルコピー パッケージインストール デーモンサービス起動 その他 アーキテクチャ 管理者ノードとリモートノードの間では、SSHプロトコルを利用して通信を行っている。そのため、Ansible環境を設定する時に、管理者ノードからリモートノードへSSHログインできることが必要である。ただし、SSHログインはパスワードレスに設定しなければいけない。詳細な設定方法は後ほど説明する。 SSH接続 管理者ノードでAnsibleをインストールし、スクリプトの編集を行う。管理者ノードでAnsibleのコマンドやスクリプトを実行する時に、管理対象のサーバにSSHで接続する。管理対象のサーバの上にパッケージをインストールする必要がない。 多種類のサーバに対応 AnsibleはRedHat系、Debian系のLinuxと、Windows系のサーバを同時に管理することができる。管理者ノードはスクリプトを実行する時のみリモートサーバに接続するため、他の同期処理がない。そのため、通常の状態では、停電などの異常状態はAnsibleを影響しない。 Ansible Towerのアーキテクチャ なぜAnsible Towerが必要なのか？ Ansible Towerは企業向けの有償ソフトウェアである。 前章のAnsible アーキテクチャとこれからのAnsibleのインストールでは、すべてのAnsibleでの管理対象となるサーバは、sshの公開鍵認証によるパスワードレスSSH接続を設定する必要がある。一般ユーザの場合、数台の仮想サーバやリモートサーバのみを管理するため特に問題ないが、企業ユーザに対し業務プロセスと安全性を確保しにくくなる。 1台のリモートサーバを追加する毎に、パスワードレスなSSH接続の設定を手動で行うことは非常に非効率的である。企業レベルのサーバが数百台、数千台規模になると、各サーバ管理者が自分の管理者ノードで全サーバに対しパスワードレスSSH接続の設定が必要となり、作業量は膨大になる。 管理者がパスワードレスSSH接続の為のssh keyを入手したり、他人にコピーしたりすると、本番環境に対し重大なセキュリティの問題になる。 Ansible Towerでなにができるのか？ Ansible Towerは企業ユーザ向けに開発されている、集中管理や権限による制限、ジョブスケジューリング機能などを提供するソフトウェアである。このソフトウェアは管理者にWebUIやREST APIを提供し、Playbookの実行やワークフローテンプレートによる条件分岐などをサポートする。 管理者は、Ansible Tower上にサーバのssh keyを使用したりシェアしたりすることができるが、ssh keyの内容参照やコピーすることはできない。 Ansible Towerでは、各管理者がシェアしているplaybookスクリプトを参照するとこができるため、重複する作業を減らすことができる。 また、Ansible Towerは現在すべてのサーバでのplaybookの実行状況を集計/表示するため、状態の確認や統計もできる。 下記の図でAnsible Towerのアーキテクチャを示している。 https://wenhan.blog/posts/20180326_the-different-between-server-side-heal-and-client-side-heal-in-glusterfs/ Mon, 26 Mar 2018 09:56:21 +0000 https://wenhan.blog/posts/20180326_the-different-between-server-side-heal-and-client-side-heal-in-glusterfs/ GlusterFSには2種類のヒール（修復）機能があり、サーバーサイドヒールとクライアントサイドヒールがあります。 サーバーサイドヒールは、すべてのGlusterサーバーノード上でself-healデーモンによって自動的に実行されます。これは、ブリックパス上の.glusterfsディレクトリからファイルやディレクトリ情報をクロールして修復を行います。そのため、ファイルデータやメタデータをサーバー側で一貫性のある状態に保ちます。 一方、クライアントサイドヒールは異なり、クライアントがマウントパスからファイルにアクセスしたとき（ファイルディスクリプタでの操作時）に、その特定のファイルに対してヒールをトリガーします。これにより、各ファイルアクセス時に追加の関数呼び出しが発生し、パフォーマンスに影響を与える場合があります。 クライアントサイドヒールはデフォルトで有効になっており、以下のコマンドで無効化できます。 ファイルデータ 1 gluster volume set <volume name> cluster.data-self-heal off エントリデータ（ディレクトリの内容やエントリ） 1 gluster volume set <volume name> cluster.entry-self-heal off メタデータ 1 gluster volume set <volume name> cluster.metadata-self-heal off クライアントサイドヒールを無効にしても、データの整合性や一貫性が損なわれるわけではありません。ファイルの読み取り時には、レプリカコピーのpending xattrが評価され、正しいコピーからのみ読み取りが行われます。ファイルの書き込み時には、新しいデータが両方のレプリカブリックに書き込まれ、Glusterノード上のself-healデーモンが必要に応じて修復を行います。 https://wenhan.blog/posts/20180218_failed-at-yum-update-and-how-to-fix-it/ Sun, 18 Feb 2018 16:46:33 +0000 https://wenhan.blog/posts/20180218_failed-at-yum-update-and-how-to-fix-it/ CentOS 7でyum updateを実行した際、エラーが発生し、OSのアップデートに失敗しました。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 # yum update Loaded plugins: fastestmirror Determining fastest mirrors * base: centos.gbeservers.com * epel: linux.mirrors.es.net * extras: linux.mirrors.es.net * ius: hkg.mirror.rackspace.com * updates: mirror.atlantic.net File "/usr/libexec/urlgrabber-ext-down", line 28 except OSError, e: ^ SyntaxError: invalid syntax File "/usr/libexec/urlgrabber-ext-down", line 28 except OSError, e: ^ SyntaxError: invalid syntax File "/usr/libexec/urlgrabber-ext-down", line 28 except OSError, e: ^ SyntaxError: invalid syntax File "/usr/libexec/urlgrabber-ext-down", line 28 except OSError, e: ^ SyntaxError: invalid syntax File "/usr/libexec/urlgrabber-ext-down", line 28 except OSError, e: ^ SyntaxError: invalid syntax Exiting on user cancel どうやらシステムに問題があるようです。調べてみると、原因はPythonのバージョンの不一致でした。‘yum’コマンドは/usr/bin/pythonのシンボリックリンクがpython2. https://wenhan.blog/posts/20180218_docker-basic-foundation/ Sun, 18 Feb 2018 16:35:32 +0000 https://wenhan.blog/posts/20180218_docker-basic-foundation/ CentOS 7、Docker 1.12.6 をベースに解説します。 Dockerのインストール Linux OSにDockerをインストールするための事前要件： Dockerは64ビットOSでのみインストール可能です。 カーネルバージョンは3.10以上が推奨されます。 cgroupとnamespaceを有効にする必要があります。 現在、CentOSやFedoraではDockerのインストールが簡単になっており、 以下のようにyumコマンドで検索できます： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 $ yum search docker | grep ^docker docker-client.x86_64 : Client side files for Docker docker-client-latest.x86_64 : Client side files for Docker docker-common.x86_64 : Common files for docker and docker-latest docker-compose.noarch : Multi-container orchestration for Docker docker-distribution.x86_64 : Docker toolset to pack, ship, store, and deliver docker-latest-logrotate. https://wenhan.blog/posts/20180201_how-to-disable-ipv6-inside-a-container-pod-in-openshift/ Thu, 01 Feb 2018 15:46:56 +0000 https://wenhan.blog/posts/20180201_how-to-disable-ipv6-inside-a-container-pod-in-openshift/ OpenShiftのコンテナ/PodはIPv4プロトコルでデータを転送するため、通常はIPv6の設定を気にする必要はありません。しかし、場合によっては他のコンテナ/PodやホストOSに影響を与えず、コンテナ内だけでIPv6を無効化したいことがあります。 以下は、コンテナから出力されたIPv6情報の例です。 1 2 3 4 5 6 7 8 9 10 11 12 13 [root@ocp37 ~]# oc exec django-ex-4-6gmsj -- ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: eth0@if45: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP link/ether 0a:58:0a:80:00:24 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 10. https://wenhan.blog/posts/20171211_gluster-filename-and-gfid/ Mon, 11 Dec 2017 15:41:23 +0000 https://wenhan.blog/posts/20171211_gluster-filename-and-gfid/ テストファイルの作成 gluster ボリュームをマウントしてファイルを作成します。 1 2 3 4 [root@client-1 ~]# mount -t glusterfs gluster-node-1:/vol /mnt [root@client-1 ~]# mkdir -p /mnt/hoge/hello-gluster/ [root@client-1 ~]# touch /mnt/hoge/hello-gluster/file [root@client-1 ~]# umount /mnt/ Gluster ボリューム内のファイルの GFID を取得 ブリックディレクトリから gluster ノードにログインし、ブリックディレクトリ内のファイルを探します。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 [root@gluster-node-1 ~]# gluster volume info vol Volume Name: vol Type: Replicate Volume ID: 4ac36bcc-7127-48c4-ac21-421850d8bc47 Status: Started Snapshot Count: 0 Number of Bricks: 1 x 3 = 3 Transport-type: tcp,rdma Bricks: Brick1: gluster-node-1:/gluster/brick-vol <-- ブリックパスを確認 Brick2: gluster-node-2:/gluster/brick-vol Brick3: gluster-node-3:/gluster/brick-vol Options Reconfigured: performance. https://wenhan.blog/posts/20171124_awk-time-functions/ Fri, 24 Nov 2017 08:34:34 +0000 https://wenhan.blog/posts/20171124_awk-time-functions/ dateコマンド以外にも、awkには時刻変換に役立つ以下の組み込み関数があります。 systime() 現在時刻をエポック（1970-01-01 00:00:00）からの秒数で返します。 1 2 3 4 $ awk 'BEGIN { print "Number of seconds since the Epoch = " systime() }' Number of seconds since the Epoch = 1511480989 mktime(YYYY MM DD HH MM SS) 日付文字列 “YYYY MM DD HH MM SS” をエポックからの秒数に変換します。systimeと同じ形式の出力です。 1 2 3 4 $ awk 'BEGIN { print "Number of seconds since the Epoch = " mktime("2017 11 24 08 52 10") }' Number of seconds since the Epoch = 1511481130 strftime() 指定したフォーマットでタイムスタンプを整形します。 https://wenhan.blog/posts/20171102_how-to-check-if-a-disk-is-ssd-or-hdd/ Thu, 02 Nov 2017 08:27:14 +0000 https://wenhan.blog/posts/20171102_how-to-check-if-a-disk-is-ssd-or-hdd/ LinuxはSSDを自動的に検出します。 カーネルバージョン2.6.29以降、以下のコマンドで/dev/sdaを確認できます。 1 # cat /sys/block/sda/queue/rotational 返り値が0なら/dev/sdaはSSD、1ならHDDです。 なお、ハードウェアRAIDで作成されたディスクの場合、このコマンドは動作しないことがあります。 もう一つの方法は、util-linuxパッケージの一部であるlsblkコマンドを使うことです。 1 2 3 4 # lsblk -d -o name,rota NAME ROTA sda 0 sdb 1 ROTAは回転デバイスを意味し、1がHDD、0がSSDを示します。 このコマンドは/sys/block/.../queue/rotationalと同じ情報を表示します。 参考: How to know if a disk is an SSD or an HDD https://wenhan.blog/posts/20170919_how-to-sort-ps-command-output/ Tue, 19 Sep 2017 14:11:37 +0000 https://wenhan.blog/posts/20170919_how-to-sort-ps-command-output/ psコマンドにはプロセスをソートできる--sortオプションがあります。 1 2 3 4 5 --sort spec ソート順を指定します。ソート構文は [+|-]key[,[+|-]key[,...]] です。STANDARD FORMAT SPECIFIERSセクションから複数文字のキーを選択します。 「+」は省略可能で、デフォルトは昇順（数値または辞書順）です。kと同じです。 例: ps jax --sort=uid,-ppid,+pid メモリでps出力をソートする メモリ使用量が多い順（高→低） 一番上が最大値になります。 1 ps aux --sort -rss メモリ使用量が少ない順（低→高） 一番下が最大値になります。 1 ps aux --sort rss CPU使用率でps出力をソートする CPU使用率が高い順（高→低） 一番上が最大値になります。 1 ps aux --sort -pcpu CPU使用率が低い順（低→高） 一番下が最大値になります。 1 ps aux --sort rss その他のソート指定子 psコマンドのmanページを参照してください。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 STANDARD FORMAT SPECIFIERS 出力フォーマット（-oオプション等）やGNUスタイルの--sortオプションで使用できるキーワード一覧です。 例: ps -eo pid,user,args --sort user このpsは他の実装で使われている多くのキーワードも認識しようとします。 args, cmd, comm, command, fname, ucmd, ucomm, lstart, bsdstart, start などはスペースを含む場合があります。 一部のキーワードはソートに使えない場合があります。 CODE HEADER 説明 %cpu %CPU プロセスのCPU使用率（##. https://wenhan.blog/posts/20170911_beginner-guide-of-systemd-on-centos7-rhel7/ Mon, 11 Sep 2017 10:19:16 +0000 https://wenhan.blog/posts/20170911_beginner-guide-of-systemd-on-centos7-rhel7/ systemdの紹介 CentOS 7やRHEL 7以前では、System Vがシステムコントローラーとして使われていました。 システムコントローラーは、すべてのプロセスやサービス、起動タスクを管理できます。 System Vはスクリプトでタスクを管理するため、パフォーマンス上の問題があり、 タスクを直列でしか起動できず、システムの起動が遅くなります。 CentOS 7からは、systemdが新しいシステムコントローラーとなりました。 最大の変化は、タスクを並列で起動できるようになり、起動速度が向上したことです。 また、systemdのPIDは1であり、システム内のすべてのプロセスを管理しています！ この記事では、systemdによる「サービス」「起動タスク」「ログ管理」について紹介します。 サービスの状態確認 システム内のすべてのサービスを確認 1 systemctl list-unit-files --type=service PageUpやPageDownで上下に移動し、qで終了します。 実行中のすべてのサービスを確認 1 systemctl list-units --type=service サービス名の前に大きな点（●）がある場合、そのサービスに問題があります。 OS起動時に自動起動するサービスを確認 1 systemctl list-unit-files --type=service | grep enabled サービスの詳細情報を確認 1 systemctl status <サービス名> 出力には、稼働状況、PID、サービスのパス、最新10件のログが含まれます。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 systemctl status rsyslog ● rsyslog.service - System Logging Service Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2017-09-11 08:42:46 JST; 1h 57min ago Docs: man:rsyslogd(8) http://www. https://wenhan.blog/posts/20170905_systemctl-command-return-failed-to-connect-to-bus-no-such-file-or-directory-in-a-docker-container/ Tue, 05 Sep 2017 10:30:55 +0000 https://wenhan.blog/posts/20170905_systemctl-command-return-failed-to-connect-to-bus-no-such-file-or-directory-in-a-docker-container/ dockerコンテナ内でcronジョブやhttpdサーバーを有効化・起動するために systemctl コマンドを実行しようとしたところ、以下のようなエラーが出力されました。 1 2 3 4 [root@5f1f0a5cde43 app]# systemctl status crond Failed to connect to bus: No such file or directory [root@5f1f0a5cde43 app]# systemctl status httpd Failed to connect to bus: No such file or directory この問題は、docker run コマンドに --privileged パラメータを追加することで解決できます。 1 2 3 4 5 6 7 # docker images REPOSITORY TAG IMAGE ID CREATED SIZE freshcase v0.5 55acda97e409 4 minutes ago 707 MB # docker run --privileged -d freshcase # docker container list CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 81fbd5eb01cb freshcase:v0. https://wenhan.blog/posts/20170810_how-to-change-timezone-in-centos-7-or-rhel-7/ Thu, 10 Aug 2017 14:18:08 +0000 https://wenhan.blog/posts/20170810_how-to-change-timezone-in-centos-7-or-rhel-7/ 現在のタイムゾーンの確認 1 2 3 4 5 6 7 8 9 [root@rhel7 ~]# timedatectl Local time: Thu 2017-08-10 05:19:53 UTC Universal time: Thu 2017-08-10 05:19:53 UTC RTC time: Thu 2017-08-10 05:19:52 Time zone: UTC (UTC, +0000) NTP enabled: yes NTP synchronized: yes RTC in local TZ: no DST active: n/a 利用可能なタイムゾーンの一覧表示 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [root@rhel7 ~]# timedatectl list-timezones Asia/Aden Asia/Almaty Asia/Amman Asia/Anadyr Asia/Aqtau Asia/Aqtobe Asia/Ashgabat . https://wenhan.blog/posts/20170728_desktop-notifier-by-python/ Fri, 28 Jul 2017 16:37:40 +0000 https://wenhan.blog/posts/20170728_desktop-notifier-by-python/ この記事では、Pythonを使ってデスクトップ通知を送る方法を紹介します。 必要なもののインストール まず、pipでnotify2をインストールします。 1 2 3 4 5 $ pip install notify2 Collecting notify2 Downloading notify2-0.3.1-py2.py3-none-any.whl Installing collected packages: notify2 Successfully installed notify2-0.3.1 コーディング まず、notify2をインポートします。 1 import notify2 次に、d-bus接続を初期化します。 D-Busは、アプリケーション同士が通信するためのメッセージバスシステムです。 1 2 # d-bus接続の初期化 notify2.init("hello") 次に、Notificationオブジェクトを作成します。 最もシンプルな方法は以下の通りです。 1 n = notify2.Notification(None) また、通知にアイコンを追加することもできます。 1 n = notify2.Notification(None, icon = "/home/wenshi/Pictures/me.jpg") 次に、通知の緊急度レベルを設定します。 1 n.set_urgency(notify2.URGENCY_NORMAL) 他にも利用できるオプションは以下の通りです。 1 2 3 notify2.URGENCY_LOW notify2.URGENCY_NORMAL notify2.URGENCY_CRITICAL 次に、通知が表示される時間を設定できます。 set_timeoutでミリ秒単位で指定します。 1 n.set_timeout(5000) 次に、通知のタイトルと本文を設定します。 1 n.update("hello title", "hello messages") 通知はshowメソッドで画面に表示されます。 https://wenhan.blog/posts/20170714_install-chrome-browser-via-yum-in-centos-or-fedora-or-rhel/ Fri, 14 Jul 2017 09:29:58 +0000 https://wenhan.blog/posts/20170714_install-chrome-browser-via-yum-in-centos-or-fedora-or-rhel/ googleのyumリポジトリを作成 /etc/yum.repos.d/google-chrome.repo というファイルを作成し、以下の内容を追加します。 1 2 3 4 5 6 [google-chrome] name=google-chrome baseurl=http://dl.google.com/linux/chrome/rpm/stable/$basearch enabled=1 gpgcheck=1 gpgkey=https://dl-ssl.google.com/linux/linux_signing_key.pub googleリポジトリの確認 以下のコマンドでリポジトリが利用可能か確認します。 1 yum info google-chrome-stable 出力から、google-chrome-stableパッケージの最新バージョンが確認できます。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 $ yum info google-chrome-stable Fedora 26 - x86_64 - Updates 6.3 MB/s | 4.1 MB 00:00 Fedora 26 - x86_64 7.5 MB/s | 53 MB 00:07 google-chrome 73 kB/s | 3. https://wenhan.blog/posts/20170712_openshift-configure-authetication-and-user-agent-using-htpasswd/ Wed, 12 Jul 2017 14:43:47 +0000 https://wenhan.blog/posts/20170712_openshift-configure-authetication-and-user-agent-using-htpasswd/ Ansible方式でOpenShiftをインストールすると、デフォルトでidentity providerはDeny allに設定され、すべてのユーザーのアクセスが拒否されます。ユーザーのアクセスを許可するには、別のidentity providerを選択し、master設定ファイルを編集する必要があります。デフォルトのmaster設定ファイルは*/etc/origin/master/master-config.yaml*にあります。 OpenShiftには複数のidentity providerがあり、ユーザー認証の管理が可能です。今回はHTPasswdを使います。 詳細はConfiguring Authentication and User Agentを参照してください。 パッケージのインストール htpasswdユーティリティはhttpd-toolsパッケージに含まれています。 1 yum install httpd-tools master設定ファイルの編集 1 2 3 4 5 6 7 8 9 10 11 oauthConfig: ... identityProviders: - name: my_htpasswd_provider challenge: true login: true mappingMethod: claim provider: apiVersion: v1 kind: HTPasswdPasswordIdentityProvider file: /path/to/users.htpasswd atomic-openshift-masterを再起動して設定を反映させます。 1 systemctl restart atomic-openshift-master ユーザー名とパスワードの設定 HTPasswdはフラットファイルでユーザー名とパスワード（ハッシュ化）を管理します。以下のコマンドでファイルを作成し、usernameのパスワードを入力します。 1 2 3 4 $ htpasswd -c </path/to/users.htpasswd> user1 New password: Re-type new password: Adding password for user user1 -bオプションを付けるとパスワードをコマンドラインで指定できます。 https://wenhan.blog/posts/20170707_openshift-use-ansible-to-install-openshift-to-multi-nodes/ Fri, 07 Jul 2017 15:32:15 +0000 https://wenhan.blog/posts/20170707_openshift-use-ansible-to-install-openshift-to-multi-nodes/ この記事では、ansibleを利用したatomic-openshift-installerコマンドによる複数ノードへのOpenShiftのクイックインストール方法を紹介します。 ホスト準備 OpenShiftノードとして以下の仮想マシンを使用します。 タイプ CPU メモリ HDD ホスト名 OS マスター 1 2 GB 20 GB master.example.com RHEL 7 ノード 1 2 GB 20 GB node1.example.com RHEL 7 ノード 1 2 GB 20 GB node2.example.com RHEL 7 ホスト登録 注意: RHEL以外のOSを使用している場合は、「## 必要なパッケージのインストール」セクションに進み、必要なパッケージをインストールしてください。インストールできない場合は、リポジトリを追加するか、rpmファイルを取得してください。 各ホストをRHSM(Red Hat Subscription Manager)に登録し、必要なパッケージにアクセスできるようにします。 各ホストでRHSMに登録: 1 # subscription-manager register --username=<user_name> --password=<password> 利用可能なOpenShiftサブスクリプションを一覧表示: 1 # subscription-manager list --available --matches '*OpenShift*' OpenShift Container PlatformサブスクリプションのプールIDを見つけてアタッチ: 1 # subscription-manager attach --pool=<pool_id> すべてのリポジトリを無効化し、OpenShift Container Platform 3. https://wenhan.blog/posts/20170704_how-to-copy-paste-text-to-from-the-system-clipboard-in-vim/ Tue, 04 Jul 2017 11:44:42 +0000 https://wenhan.blog/posts/20170704_how-to-copy-paste-text-to-from-the-system-clipboard-in-vim/ VIMが+clipboard対応であることを確認する .vimrcに「set clipboard=unnamedplus」を追加する +clipboardが有効か確認する 1 2 3 $ vim --version | grep clipboard +clipboard +job +path_extra +user_commands +eval +mouse_dec +statusline +xterm_clipboard ‘-clipboard’と表示された場合は、この機能付きでVIMをコンパイルする必要があります。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 $ git clone https://github.com/vim/vim.git $ cd vim/src/ $ ./configure --with-features=huge \ --enable-multibyte \ --enable-rubyinterp=yes \ --enable-pythoninterp=yes \ --with-python-config-dir=/usr/lib64/python2.7/config \ --enable-perlinterp=yes \ --enable-luainterp=yes \ --prefix=/usr/local/ \ --enable-fail-if-missing \ --enable-gui=no \ --enable-tclinterp=yes \ --enable-cscope=yes \ --enable-gpm \ --enable-cscope \ --enable-fontset \ --with-x \ --with-compiledby=koturn $ make -j5 # これで. https://wenhan.blog/posts/20170629_how-to-keep-process-script-running-after-end-the-ssh-session/ Thu, 29 Jun 2017 14:31:14 +0000 https://wenhan.blog/posts/20170629_how-to-keep-process-script-running-after-end-the-ssh-session/ tmuxはこれを実現できるオープンソースソフトウェアです。他にも多くの機能がありますが、ここではsshセッションを終了してもプロセスを動かし続ける方法を説明します。手順は以下の通りです： シェルでtmuxと入力してtmuxセッションを開始します。 tmuxセッション内でプロセスやスクリプトを起動します。 Ctrl+bを押してからdを押すことで、tmuxセッションから離脱（デタッチ）します。 これでsshセッションを切断・ログオフしても、プロセスやスクリプトはtmuxセッション内で動き続けます。再度状態を確認したい場合は、再ログインしてtmux attachでセッションに再接続できます。 現在動作中のセッションはtmux list-sessionsで一覧表示できます。 tmuxはさらに多くの機能があります。詳細はman tmuxを参照してください。 https://wenhan.blog/posts/20170626_vim-use-built-in-spell-check/ Mon, 26 Jun 2017 16:37:57 +0000 https://wenhan.blog/posts/20170626_vim-use-built-in-spell-check/ VIMはバージョン7から標準でスペルチェック機能を搭載していますが、デフォルトでは無効になっています。 有効化/無効化 :set spell と :set nospell でスペルチェックの有効・無効を切り替えられます。スペルチェックは英語だけでなく他言語にも対応しています。現在の対象言語は :echo &spelllang で確認できます。ターゲット言語の変更は :set spelllang=en_GB.UTF-8 のように指定します。複数言語を設定したい場合は set spelllang=en_us,nl,medical のようにカンマ区切りで指定できます。 スペルミスの確認 ]s で次のスペルミスへ、[s で前のスペルミスへ移動します。 ミスの修正 z= で修正候補をリスト表示し、番号を入力して選択します。 特定の単語をユーザー辞書に追加したい場合は zg、削除したい場合は zw を使います。 まとめ command action :set spell スペルチェック有効化 :set nospell スペルチェック無効化 ]s 次のミスへ移動 [s 前のミスへ移動 z= 修正候補を表示 zg 単語を追加 zw 単語を削除 https://wenhan.blog/posts/20170626_openshift-install-openshift-and-create-first-project-hello-openshift/ Mon, 26 Jun 2017 13:40:40 +0000 https://wenhan.blog/posts/20170626_openshift-install-openshift-and-create-first-project-hello-openshift/ Linux OSのインストールとネットワーク設定の確認 OpenShiftをインストールするにはLinux OSマシンが必要です。最小要件は以下の通りです。 CPU メモリ ハードディスク ネットワーク x86_64 1コア 2 GB 20 GB IPv4 まずCentOS 7.3を最小構成でインストールします。インストール後、IPアドレスを確認し、利用可能なIPがあることを確認します。以下はeth0のIPアドレスが"192.168.122.45"である例です。 1 2 [root@openshift ~]# ip a ...（省略: コマンド出力は英語のまま）... OpenShiftはサービス提供のためにホスト名が必要です。“hostnamectl set-hostname"でホスト名を設定し、“hostname"で確認します。以下はホスト名が"openshift.example.com"である例です。 1 2 3 [root@openshift ~]# hostnamectl set-hostname openshift.example.com [root@openshift ~]# hostname openshift.example.com dockerのインストール OpenShiftはコンテナエンジンとしてdockerを使用します。以下のコマンドでdockerをインストールします。 1 [root@openshift ~]# yum install -y docker インストール後、dockerサービスを起動し有効化します。 1 2 [root@openshift ~]# systemctl start docker [root@openshift ~]# systemctl enable docker 下記コマンドでdockerがインターネットからデータを取得できるか確認します。以下は"hello-openshift"コンテナを作成する例です。この小さなアプリはGoで書かれており、8080と8888ポートでリッスンします。（初回実行時はイメージがローカルにないため、ダウンロードに時間がかかります） 1 2 [root@openshift ~]# docker run -it openshift/hello-openshift . https://wenhan.blog/posts/20170616_how-to-clear-memory-cache-buffer-and-swap-on-linux/ Fri, 16 Jun 2017 12:05:35 +0000 https://wenhan.blog/posts/20170616_how-to-clear-memory-cache-buffer-and-swap-on-linux/ Linuxでキャッシュをクリアする方法 PageCacheのみをクリア 1 sync ; echo 1 > /proc/sys/vm/drop_caches Dentryとinode（メタデータ）をクリア 1 sync ; echo 2 > /proc/sys/vm/drop_caches すべてのキャッシュ（PageCache、Dentry、inodeを含む）をクリア 1 sync ; echo 3 > /proc/sys/vm/drop_caches Linuxでスワップ領域をクリアする方法 1 swapoff -a && swapon -a 注意：すでにRAMが少ない場合、この操作はシステムを不安定にする可能性があります。 スワップ領域のデータがRAMに強制的に移動され、RAMに空きがない場合はOOM（メモリ不足）になることがあります。 https://wenhan.blog/posts/20170615_glusterfs-failed-to-probe-a-cloned-peer/ Thu, 15 Jun 2017 11:43:46 +0000 https://wenhan.blog/posts/20170615_glusterfs-failed-to-probe-a-cloned-peer/ もし gluster システムのセットアップ時間を短縮したい場合、1台のVMで必要な設定をすべて行い、それをクローンする方法があります。 しかし、別ノードからピアをプローブしようとすると問題が発生することがあります。 コマンドを実行すると、次のようなエラーメッセージが表示される場合があります： 1 2 [root@node1 ~]# gluster peer probe node2 peer probe: failed: Peer uuid (host node2) is same as local uuid これは、glusterfs-server パッケージが最初にインストールされた際、ノードUUIDファイルが /var/lib/glusterd/glusterd.info に作成されるためです。 そのため、glusterfs をインストール済みのVMをクローンすると、同じUUIDを持つ glusterd.info がすべてのVMに保存されてしまいます。 解決方法は以下の通りです： すべてのノードで glusterd サービスを停止する /var/lib/glusterd/glusterd.info を削除する すべてのノードで glusterd サービスを起動する 再度 peer probe コマンドを実行する ステップ3の後、新しいUUIDを持つ glusterd.info ファイルが作成され、この問題は解消されます。 https://wenhan.blog/posts/20170427_linux-special-permissions-for-file-and-dir.jp/ Thu, 27 Apr 2017 23:59:20 +0000 https://wenhan.blog/posts/20170427_linux-special-permissions-for-file-and-dir.jp/ 特殊パーミションの説明 ファイルとフォルダに対し、setuid、setgid、sticky bitの三つの特殊パーミッションが存在する。 setuidとsetgidパーミッションは、コマンドを実行したユーザまたはグループではなく、ファイルの所有者として実行したことを意味する。 sticky bitパーミッションは、ファイルの削除に関する特殊な制限があり、ファイルの所有者及びrootのみがディレクトリ内のファイルを削除できるようになっている。 特殊パーミッション ファイルへの影響 フォルダへの影響 u+s(suid) ファイルを実行したユーザではなく、ファイルの所有者としてファイルが実行される。 影響なし g+s(sgid) ファイルが所属するグループとして実行される。 フォルダ内に新規作成したファイルの所有グループは、フォルダの所有グループと同じになる。 o+t(sticky) 影響なし フォルダに書き込みパーミションを持つユーザは、自分が所有しているファイルのみ削除できる。他のユーザが所有するファイルの削除または編集はできない。 特殊パーミションの設定 記号を使用: setuid = u+s; setgid = g+s; sticky = o+t 数字を使用: setuid = 4; setgid = 2; sticky = 1 例 1 2 chmod g+s file # fileに対してsetgidビットを追加 chmod 1755 file # fileに対してstickyビットを追加 https://wenhan.blog/posts/20170427_linux-password-aging.jp/ Thu, 27 Apr 2017 23:15:00 +0000 https://wenhan.blog/posts/20170427_linux-password-aging.jp/ Linuxのユーザパスワードの有効期限(aging)の管理について説明する。 last chage (-d) : パスワードが最後に変更した日数 min days (-m) : パスワードが変更可能の最小日数 max days (-M) : パスワードの変更が必要となる最大日数 warn days (-W) : パスワードの有効期限が近づき、変更を促す（ワーニング）の日数 password expiration date : パスワード有効期限 inactive days (-l) : パスワードの有効期限が切れた後に、アカウントが保持される日数 inactive date : アカウントが非アクティブになる期限 上記情報の変更は、chage コマンドで実現できる。 1 chage -m 0 -M 60 -W 7 -l 30 また、chage コマンドに対し以下の使い方もある。 次回ログイン時に強制パスワードを変更させる 1 chage -d 0 username 現在の設定一覧を表示 1 chage -l username 指定した日付でアカウントが期限切れになる 1 chage -E YYYY-MM-DD username ユーザアカウントに関連する内容で他にも ロックとアンロック 1 2 usermod -L username usermod -U username https://wenhan.blog/posts/20170427_soft-link-and-hard-link/ Thu, 27 Apr 2017 22:14:48 +0000 https://wenhan.blog/posts/20170427_soft-link-and-hard-link/ ソフトリンクとハードリンクの違いについてメモする 他にも思い出したらまた追記する。 項目 ソフトリンク ハードリンク size 4 byte 表示上元ファイルと同じ inode 元ファイルと異なるinodeを持つ 元ファイルと同じinodeを持つ 制限 - 元ファイルと同じファイルシステム上にある必要がある 以下でリンクのサイズとinode番号の違いがわかるはず。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 wenhanMBP: /tmp/link → ls -li total 1024 12807105 -rw-r--r-- 1 shiwenhan wheel 524288 4 27 22:18 file wenhanMBP: /tmp/link → ln file hardlink-to-file wenhanMBP: /tmp/link → ls -li total 2048 12807105 -rw-r--r-- 2 shiwenhan wheel 524288 4 27 22:18 file 12807105 -rw-r--r-- 2 shiwenhan wheel 524288 4 27 22:18 hardlink-to-file wenhanMBP: /tmp/link → ln -s file softlink-to-file wenhanMBP: /tmp/link → ls -lih total 2056 12807105 -rw-r--r-- 2 shiwenhan wheel 512K 4 27 22:18 file 12807105 -rw-r--r-- 2 shiwenhan wheel 512K 4 27 22:18 hardlink-to-file 12807448 lrwxr-xr-x 1 shiwenhan wheel 4B 4 27 22:27 softlink-to-file -> file https://wenhan.blog/posts/20170421_fix-hexo-error-output-build-release-dtraceproviderbindings/ Fri, 21 Apr 2017 00:56:19 +0000 https://wenhan.blog/posts/20170421_fix-hexo-error-output-build-release-dtraceproviderbindings/ hexoコマンドを実行するたびに、以下のようなうるさいエラーメッセージが表示されます。 1 Error: Cannot find module './build/Release/DTraceProviderBindings' これは単なるトレースエラーで作業自体は止まりませんが、とてもノイズで、どうしても消したいと思いました。 以下のリンクから、 https://github.com/hexojs/hexo/issues/1922 https://github.com/yarnpkg/yarn/issues/1915 原因はdtrace-providerパッケージであることが分かりました。 自分はこのパッケージを全く使っていないので、アンインストールしたいだけです。 1 npm uninstall dtrace-provider -g しかし、このパッケージはhexoに関連しているため、削除されません… 以下のコマンドでまだ存在することが確認できます。 1 npm list | grep dtrace では、環境をクリーンアップするために、hexo-cliとdtrace-providerの両方をアンインストールします。 注意: コマンドはsudoで実行してください 1 2 sudo npm uninstall hexo-cli -g sudo npm uninstall dtrace-provider -g 次に、hexo-cliを–no-optionalオプション付きでインストールし、dtrace-providerがインストールされていないことを確認します。 注意: コマンドはsudoで実行してください 1 sudo npm install hexo-cli --no-optional -g これで、世界が再び静かになりました。:) https://wenhan.blog/posts/20170421_get-weather-info-and-send-by-gmail-python/ Fri, 21 Apr 2017 00:16:17 +0000 https://wenhan.blog/posts/20170421_get-weather-info-and-send-by-gmail-python/ 天気予報を見ずに何度か大雨に降られたので、同じようなズボラな人のために小さなプログラムを書いてみました。 とてもシンプルで、Pythonのちょっとした練習にもなります。Pythonで毎日天気をメールで通知する仕組みです。 このプログラムは2つのステップに分かれています。 Webサイトから天気情報を取得する 取得した天気情報を指定したメールアドレスに送信する 天気情報の取得 ここでは、よく使われるrequestsとBeautifulSoup4を使ってWebページから情報を取得・抽出します。 天気サイトはtenki.jpを使い、idで検索画面の天気情報ブロックを抽出します。 下記のように、BS4でidが’map_world_point_wrap’の<div>以下のHTMLを抽出すればOKです。 HTMLコードをそのまま送信することで、見た目もきれいになります。 コード例： 注：soup.findの後は内容をstring型に変換しないと、python2環境ではメール送信できません。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 #!/root/.pyenv/shims/python #-*- coding: UTF-8 -*- import sys import time import requests from bs4 import BeautifulSoup #Some User Agents hds=[{'User-Agent':'Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6'}] def weather_notice(): url='http://www. https://wenhan.blog/posts/20170415_install-vim-8-with-python/ Sat, 15 Apr 2017 00:50:08 +0000 https://wenhan.blog/posts/20170415_install-vim-8-with-python/ 今日はMac Proの開発環境を設定しました。 そしてbrewを使えばpython対応のVIM8がとても簡単にインストールできることに気づきました。 （cent7よりもずっと簡単です） brewがあれば、以下のコマンドを実行するだけです。 1 brew install --with-python vim python3とpython2の両方に対応させたい場合は、次のコマンドを実行します。 1 brew install --with-python --with-python3 vim 追記：一部の最新OSではpython2用に下記コマンドが必要な場合があります。 1 brew install --with-python@2 古いvimのバイナリファイルを削除する必要があるかもしれません。 1 rm -f /usr/local/bin/vim そしてvimを再リンクします。 1 brew link --overwrite vim これで完了！快適なvimライフを https://wenhan.blog/posts/20170216_cannot-ssh-to-server-by-root-user/ Thu, 16 Feb 2017 16:36:12 +0000 https://wenhan.blog/posts/20170216_cannot-ssh-to-server-by-root-user/ rootパスワードを知っているのに、rootでssh接続できない問題の解決方法です。 実はsshdの設定ファイルに、rootでのログイン許可を設定するパラメータがあります。 Linux環境では、設定ファイル/etc/ssh/sshd_configに対し 1 PermitRootLogin no を 1 PermitRootLogin yes に変更し、sshdを再起動すれば、アクセス出来るようになる。 1 systemctl restart sshd また、以下のように自動ログインをOFFにするパラメータも存在する 1 PubkeyAuthentication no 特定のIPに対しての個別設定も可能 1 2 Match Address 172.25.0.11 PubkeyAuthentication no https://wenhan.blog/posts/20161201_crawling-webpage-use-python-requests/ Thu, 01 Dec 2016 00:54:09 +0000 https://wenhan.blog/posts/20161201_crawling-webpage-use-python-requests/ PythonのRequestsライブラリを利用してウェブページの内容を抽出し保存する。 そして、BeautifulSoupライブラリを利用し、欲しい情報を抽出する。 Requestsとは RequestsはPythonのHTTPライブラリで、urllib2より断然使いやすい。 公式サイトに、 Requests is an Apache2 Licensed HTTP library, written in Python, for human beings. の説明の通り、人間によって読みやすくコーディングできる。 Beautifulsoupとは BeautifulSoupはPythonで動作するHTMLとXMLのパーサーです。 インストール 1 2 pip install requests pip install BeautifulSoup 使い方 1 2 import requests from bs4 import BeautifulSoup requestsライブラリでは、各種のHTTPメソッドに１対１のメソッドがあります。 1 2 3 4 5 requests.get('URL') requests.post('URL') requests.put('URL') requests.delete('URL') requests.head('URL') 初めてのスパイダー アマゾンの本のランキングの内容を取ってみよう。以下のことを要件とする。 ブラウザがアクセスしているように、ヘッダ情報を編集する。 ページの取得が成功の場合のみ、ページ内容をファイルに保存する。 売れ筋ランキングの1-20位の本の順位とタイトルを出力する。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 import requests import time from bs4 import BeautifulSoup def anaylise_ranking_books(html): soup = BeautifulSoup(html. https://wenhan.blog/posts/20161121_manage-vim-plugins-with-vundle/ Mon, 21 Nov 2016 00:37:36 +0000 https://wenhan.blog/posts/20161121_manage-vim-plugins-with-vundle/ Vimのプラグインを管理する人気のツール、Vundleの利用メモ 本家のサイト：[https://github.com/VundleVim/Vundle.vim] Vundleを利用するメリット プラグインを.vimrcでインストール/更新/削除できる 名前だけ書けば自動で探してくれる インストール 以下のコマンドで、ファイルをコピーするだけでインストール完了 1 git clone https://github.com/VundleVim/Vundle.vim.git ~/.vim/bundle/Vundle.vim 設定 以下の設定内容を.vimrcのトップに記入する。 説明のためいくつかの行がイメージになっている。 実際利用するときにコメントアウトする必要がある。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 set nocompatible " be iMproved, required filetype off " required " set the runtime path to include Vundle and initialize set rtp+=~/. https://wenhan.blog/posts/20161112_google-maps-api-with-python/ Sat, 12 Nov 2016 01:22:46 +0000 https://wenhan.blog/posts/20161112_google-maps-api-with-python/ PythonでGoogle mapsのAPI を利用しルート検索をやってみた。 利用するモジュールはgooglemaps/google-maps-services-python 環境構築は以下のコマンドでOK, ついでにipythonもインストールする。 1 2 pip install googlemaps pip install ipython あと、GoogleのAPIキーの申請が必要なので、Google APIsで申請＆有効にする。 ここまで問題なかったら、早速使ってみよう。 戸塚駅から踊場駅まで、車のルート情報を取得 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 $ ipython Python 3. https://wenhan.blog/posts/20161101_googlemap-on-ios/ Tue, 01 Nov 2016 01:16:21 +0000 https://wenhan.blog/posts/20161101_googlemap-on-ios/ GoogleマップをiPhone上に表示したい時にはまったことを残す。 Google Maps API > iOS向け > Maps SDK for iOSを参考に、とりあえず画面上GoogleMapを表示させようの所、画面が真っ白で何も表示されない。 そして、コンソールには以下のエラーメッセージが出ていた。 1 ClientParametersRequest failed, 0 attempts remaining (0 vs 6). Error Domain=com.google.HTTPStatus Code=400 ネットで調べたところ、このサイトを見つけた。 そして自分の場合は、三つ目の見直しで、自分のAPIキーが「無効」になっている。。 このエラーの原因は、だいたいAPIキーの設定に何か間違っているようです。 以下の見直しを確認すべき。 APIキーを生成するとき、xcodeのProjectのbundle IDを設定した方がいい。このパラメータは「任意」ってGoogleが言ったが、やはり設定した方が無難。 アプリのBundleIDを変更した場合、APIキーを再生成しましょう。 Google Developersのダッシュボードで「Google Maps SDK for iOS」が有効になっていることを確認しましょう。デフォルトでは無効になっている。(今回はここにはまった) 時間があったらAPIキー有効の画面もアップする予定 https://wenhan.blog/posts/20161029_python-reverse-str-to-check-palindrome/ Sat, 29 Oct 2016 01:21:18 +0000 https://wenhan.blog/posts/20161029_python-reverse-str-to-check-palindrome/ もう一題をやった。Palindrome chain length 回文に関する計算問題です。 回文とは、文字列を真ん中で割って、左辺と右辺が反転的に対称している文字列のこと。 例えば、「あいういあ」が回文であり、「あいうえお」が回文では無い。 数字の場合も同じく、5,44,171,4884が回文であり、43,194,4773が回文ではない。 そして、今回の問題は、引数の数字に対し、特定な計算方法で、何回計算したら回文になるかを算出する。 ここでの特定な計算方法は、「自分の数字の各桁を反転し、元の数字と足し算する」のこと。 例えば、87が与えられ、4回の計算で回文数字になったため、戻り値を４にする。 1 2 3 4 87 + 78 = 165; 165 + 561 = 726; 726 + 627 = 1353; 1353 + 3531 = 4884; ここで難しいのは、数字をどうやって反転するか。 いろいろ調べた結果、意外と簡単でした。しかも一行で済む。Python で文字列反転 1 2 str(n) # 数字を文字列に変換 str(n)[::-1] # 数字を文字列に変換し、逆順に変換する。 このような書き方は、「文字列の末尾から一つずつ遡って先頭まで要素を取り出す」の操作となる。 そしてさっきの問題に対し自分の答えは 1 2 3 4 5 6 def palindrome_chain_length(n): cnt=0 while str(n) != str(n)[::-1] : cnt += 1 n += int(str(n)[::-1]) return cnt いや〜便利だな〜これで今日もよく寝れる〜 https://wenhan.blog/posts/20161029_python-print-format/ Sat, 29 Oct 2016 00:28:06 +0000 https://wenhan.blog/posts/20161029_python-print-format/ 今日もCodeWarの問題を練習した。RGB To Hex Conversion 問題を簡略化にすると、rgbの数字を16進に変換し出力する。 1 2 3 4 rgb(255, 255, 255) # returns FFFFFF rgb(255, 255, 300) # returns FFFFFF rgb(0,0,0) # returns 000000 rgb(148, 0, 211) # returns 9400D3 直接hexで変換すると、”0x”が余計についているし、“00"が"0"になる。 sprintf見たいな関数が無いかなっと思いながら、このサイトを見つけた。 Cのsprintfのような文字列フォーマット なんと、フォーマットを指定すれば数字が直接変換される！桁数の指定も出来る。 そして自分の答えは 1 2 3 4 5 def limit(a): return min(max(a, 0), 255) def rgb(r, g, b): return "%02X%02X%02X" % (limit(r), limit(g), limit(b),) 便利だな~ https://wenhan.blog/posts/20161024_install-of-hexo/ Mon, 24 Oct 2016 23:15:49 +0000 https://wenhan.blog/posts/20161024_install-of-hexo/ ここのURLを参考しながら、HexoのBlogを設定した。 https://liginc.co.jp/web/programming/server/104594 Install の途中で、以下のエラーが出た。 1 2 % hexo deploy ERROR Deployer not found: github https://github.com/hexojs/hexo/issues/1040 を参考にして、直した。 1 % npm install hexo-deployer-git --save _config.ymlのtypeもgitに変更 1 2 deploy: type: git MarkDownの文法も勉強せねばな。。。やることが多い〜