平日の夕方、記事の記事を書かない方法。 Goを知ることの印象を共有したいと思います。 以下に書かれているのは、著者の主観的な意見です。 この記事は、 Goを学習するために座りたい人にとって有用であり、 Goの開発者にとってはほとんど役に立ちません。
背景
私の活動の主な種類は、 Javaの過酷なエンタープライズ環境でビジネス上の問題を解決することです。本来、私は、新しい興味深いことを学び、スキルをサポートし、新しいことを学び、じっと立ち止まることを望んでいません（一種の線形ビジネスマン ）。 このため、 Dockerの見方は長く落ちています。
そして現在のプロジェクトでは、開発者とテスターの環境でドッカープラクティスを実装し始めました。 そして、 ドッカーが表示される場所にコンテナが表示されます。CPUからネットワークI / Oまで、これらのコンテナからすべてを知りたいです。 このすべてのために、最初に標準のdocker ps
とdocker stats
。 これらは2つの別個のユーティリティであるという事実のためにいくつかの不便がありましたが、 ctopに出会うまでは全体的に眠かったです。 ドッカーを使用する多くの人はそれに慣れていると思います。
プロジェクト
マシン上でctopを実行すると、統計や、検索または並べ替えを使用してコンテナーに関する詳細情報を表示する機能を備えた美しいlike-htopコンテナーが表示されました。 一般的に、私は非常に喜んでいました。
ある時点まで、 ctopで最初に確認したいのはコンテナのヘルスチェックですが、そこにはありませんでした。 次に、 ドッカースウォームモードが表面化したため、 ctopのサービスに関する統計情報も確認したいと思います。
そしてここで腐食性の読者は疑問に思うかもしれませんが、すべてがドッカーに関するものである場合、どこに行くのですか？ および著者の個人的な意見 。
Linuxユーティリティーを自分で作成/仕上げした経験があるので、これは端末にあり、コンソール用であるため、 Pythonが必要であり、すぐに必要なものを追加できると思いました。
リポジトリーに入ったとき、 Goがそこにあるのを見て驚きました（論理的には、 dockerがそこに書かれています）。 Goについての報告から、夕方に学習できるという言葉を思い出して、彼はプログラムを完成させるための取り組みを続けました。 このサイトからドキュメントを読み、例を実行した後、私はプロジェクトに座った。
コード例
Goを知ると、 「簡潔でサポートしやすい」というフレーズがどこかで滑ってしまい、これらの声明に同意します。
異常ではあるが快適に見えた最初のものはGOPATHでした 。 セットアップと概念自体については、 ここで非常によく説明されています 。
パッケージの整理と構造化のアプローチとアクセスのレベルも興味深いように思えました。 特に、大文字および小文字によるパブリックメソッドとプライベートメソッドの宣言、およびインターフェイスの実装。 そして彼は、 ジャバの世界の人のように、兆候に信じられないほど喜んでいた。
依存関係管理は、少なくともこのプロジェクトでは、特別な問題を引き起こしませんでした（ただし、 Goはパッケージマネージャーの不足でscられました）。 import
コンストラクトで指定されているすべてのものは、 scrディレクトリのGOPATHフォルダーに収集され、依存関係は既に使用できます。 GitHubを使用すると、依存関係がプロジェクトに直接依存し、独自のモジュールの依存関係とほとんど変わらないことに注意してください（インポートロジックが最小化されます）。
import ( "fmt" "strings" "sync" "github.com/bcicen/ctop/connector/collector" api "github.com/fsouza/go-dockerclient" "github.com/bcicen/ctop/config" "context" "github.com/bcicen/ctop/entity" "github.com/docker/docker/api/types/swarm" )
ctopに関しては、その構造が非常に単純であることが判明しました。
プロジェクト構造は、3つの大きな部分に分かれています。
- コネクター
- ウィジェット
- グリッド/カーソル
コネクタ -コンテナに関する情報を提供するさまざまなサービスに接続するためのインターフェイス。 たとえば、docker、opencontainer、kubernatesなど。
main.go
クラスはコネクタディレクトリに作成され、コネクタのインターフェースを記述します。
package connector type Connector interface { All() container.Containers Get(string) (*container.Container, bool) }
そして、それを実装するには、例えばdocker.go
別のファイルを作成し、 NewDocker()
メソッドに対して、返されたインターフェイスタイプを指定し、そのアドレスを返す必要があります。
そして、上記のすべてのメソッドを実装します。 私は、1つのクラスのフレームワーク内で、インターフェースのいくつかの実装を記述できることが好きで、これは通常の慣行です。
package docker type Docker struct { client *api.Client containers map[string]*container.Container needsRefresh chan string lock sync.RWMutex } func NewDocker() Connector { client, err := api.NewClientFromEnv() if err != nil { panic(err) } cm := &Docker{ client: client, containers: make(map[string]*container.Container), needsRefresh: make(chan string, 60), lock: sync.RWMutex{}, } return cm } func (cm *Docker) All() (containers container.Containers) { cm.lock.Lock() for _, c := range cm.containers { containers = append(containers, c) } containers.Sort() containers.Filter() cm.lock.Unlock() return containers } func (cm *Docker) Get(id string) (*container.Container, bool) { cm.lock.Lock() c, ok := cm.containers[id] cm.lock.Unlock() return c, ok }
func
後の括弧内にfunc
、メソッドが実装されている構造func
示されており、非常に便利に見えます。
cwidgets-完成したインターフェースが組み立てられる個々のグラフィック要素。
グリッド/カーソル -表示のためにすべてを収集し、アクセスおよび制御方法を提供するパッケージ。
ヘルスチェックマッピングの実装は非常に簡単でした。 docker.go
では、 health
属性をメタ情報に追加しました。これは、 docker inspect <CONTAINER>
機能と同じ方法でapiを介して読み取られます。 値に応じて、 NAME
列のテキストの色を変更します。
しかし、 スウォームモードの追加がより興味深いことがわかりました。
swarmモードでは、 node
、 service
およびtask
概念が表示されます。 そして、それらの間には、誰がどこにいる関係を表示する必要があります。 そして、これはctopでは提供されませんでした 。 そして、ここで私は本当に良いコードサポートを感じました。 コンテナの構造には、メタ情報とグラフィカルインターフェイスにアクセスするためのメソッドが含まれていました。これらのメソッドは、新しく導入されたコンセプトに必要な別のインターフェイスに簡単に移動できます。 インターフェイスは次のようになります。
package entity import ( "github.com/bcicen/ctop/logging" "github.com/bcicen/ctop/connector/collector" "github.com/bcicen/ctop/models" ) var ( log = logging.Init() ) type Entity interface { SetState(s string) Logs() collector.LogCollector GetMetaEntity() Meta GetId() string GetMetrics() models.Metrics }
ここでは、このインターフェイスを実装するすべてのクラスに共通のlog
変数が宣言され、インターフェイスコントラクトが説明されています：要素の状態を変更する方法、変数log
を介した特定の要素のlog
へのアクセス、要素のメタ情報へのアクセス、およびそのメトリックへのアクセス。
インターフェイスを記述し、すべての構造に実装し、 grid
メソッドで古いcontainer
を新しいentity
に置き換えた後、1つの興味深い質問が出されました。 Dockerは現在、 APIツールを使用してリモートノードからリソースの使用に関する情報を取得する機能を提供していません。 そのため、私はswarmクラスターの出力構造の実装とヘルスチェック起動タスクに落ち着きました。
印象と結論
一般に、プロジェクトでGoを使用することに非常に満足しており、言語は実際に実用的で簡潔になりました。 彼はどういうわけか、 PythonとC ++の混合物を思い起こさせ、そこから彼らはすべてを最大限に活用しようとしました。 あなたは本当に夕方にそれを学ぶことができます。 しかし、夕方から文章を書き始めるには、十分な背景知識が必要であり、学習のための第一言語としてはお勧めしません。 おそらくその利便性を理解する必要があります。 また、私自身のために、筆記サービスという形で言語のニッチを特定しました（おそらくこのために設計されたのでしょう）。
ctopについては、マイナーはヘルスチェック表示でプルリクエストを受け入れました。今、 スウォーム構造の表示を終了する予定です。 リモートノードからコンテナメトリックの読み取りを実装する方法を提案できることを嬉しく思います。