トレースの情報を上位のレイヤーに渡すだけならパッケージで定義したエラーの型は公開しない トレースの情報だけをラップして渡していきたい場合には、Formatを実装していればパッケージ内で独自に定義したエラータイプは非公開にして問題ありません。非公開の場合は、Isでマッチなどはすることはありません。しかし Unwrap を実装しないと、より下位にラップされた公開されているエラーに到達できなくなってしまうので注意が必要です。 package pkg1 import ( "fmt" "golang.org/x/xerrors" ) // 非公開の型 type pkg1Error struct { msg string err error frame xerrors.Frame } func (e *pkg1Error) Error() string { return e.msg } // Unwr
この記事は Kubernetes道場 Advent Calendar 2018 9日目の記事です。 今回はServiceについて。 Serviceについて ServiceはPodへの接続を解決してくれる抽象的なオブジェクトだ。端的にはSelectorで選択したPodをUpstreamとしたLBだ。 Serviceには4つの種類がある。 ClusterIP NodePort LoadBalancer ExternalName それぞれ見ていこう。 ClusterIP ClusterIPはKubernetes内での通信で利用する。クラスタ内でIPアドレスが払い出され、それを利用してPod間で通信を行う。 ClusterIPの設定について clusterIP clusterIP にIPアドレスを指定することで指定されたIPアドレスでServiceが作成される。 空文字や指定しなかった場合、ランダ
社内でIstioを導入した際に、チュートリアルなどではわかりにくいハマりポイントや、既存GKEクラスタの導入にあたって留意すべき点がけっこうあるなと思ったのでまとめます。 対象読者は GKEですでにサービスなどを運用している Istioの概要は知っている、またはチュートリアルは終わった くらいの方を想定しています。 なお、Istioとはなにかを解説する記事はすでにたくさんあるので、できるだけ作業レベルで導入の仕方を解説していきます。 Istioを知るハンズオンとしては、Googleの中の方のIstio 1.0 を試してみた!などが良いです。 移行したいアプリの構成 もともとの構成はこんな感じでした。 GCP上でglobal IPを取得し、FQDNと紐づけて外部流入をさせる トラフィックはIngressで受けており、SSL terminationを行う Ingressの次にNginxがあり、
僕はGolangで開発する際、Neovimを使用しています。 Golangのバージョンアップに伴い、gocodeによる補完がうまく動かなくなったりと色々と問題が発生したので、プラグインや設定の見直しを行いました。その際の備忘録を書いていきます。 前置き プラグインマネージャーにはdeinを使わせてもらっているので、他のツールを使っている方は適宜読み替えていただけると助かります。 メインで利用するプラグインは以下の通りです。 vim-go LanguageClient-neovim deoplete 以前まではvim-goのみで補完や文法チェック、フォーマッティングまで全部お任せできていたのですが、上述したようにgocodeを利用した補完が難しくなったため、LSP(Language Server Protocol)に一部機能を任せる形に設定しています。 Golangにおけるgocode/LS
nnoremap [denite] <Nop> nmap <C-c> [denite] "現在開いているファイルのディレクトリ下のファイル一覧。 nnoremap <silent> [denite]f :<C-u>DeniteBufferDir \ -direction=topleft -cursor-wrap=true file file:new<CR> "バッファ一覧 nnoremap <silent> [denite]b :<C-u>Denite -direction=topleft -cursor-wrap=true buffer<CR> "レジスタ一覧 nnoremap <silent> [denite]r :<C-u>Denite -direction=topleft -cursor-wrap=true -buffer-name=register register<CR> "最
Check out our Cloud Native Services and book a call with one of our experts today! I recently got into orchestrating my Docker containers with Kubernetes. For one of our projects, I needed to pull docker images from the Google Container Registry (GCR). When using the Google Kubernetes Engine with the GCR everything works out of the box, but to run the containers locally with docker, I had to insta
zshでのgitコマンドの入力補完を設定する方法はいくつかあるようですが、最近はgitのソースツリーにcontrib/completion/git-completion.zshというものが含まれているので、今回はそれを利用する手順を紹介します。 設定を行うと、以下のようにコマンドやリモートリポジトリ、ブランチ名の補完ができるようになります。 今回、動作を確認した環境は以下の通りです。 Mac OS X 10.8.3 zsh 5.0.2 git 1.8.2.3 zshとgitをHomebrewでインストールしている場合は、zshの設定を行うだけで作業完了です。git 1.8.2.2に含まれる補完定義ファイルとgit 1.8.2.3に含まれるそれとでは結構違いがあるようなので(コミットログ)、gitはできるだけ最新版にアップデートしておきましょう。 Homebrewを使っていない場合は、補完定
この記事は Aizu Advent Calendar の 20 日目の記事です。 adventar.org 前日は id:nktafuse の 、 nktafuse.hatenablog.com 明日は id:ywkw1717 です。 ywkw1717.hatenablog.com きっかけ 最近職場で Clean Architecture を取り入れたアプリケーションを Python で書いていて、Go でも書けないか?という試みではじめました。 作ったものは、サーバにアップロードしたファイル自体の改竄を検出できる簡易ファイルアップローダみたいなものです。 github.com 以下では CA について簡単に解説した後、設計・実装する上で悩んだ点などを挙げています。 Clean Architecture 原文と翻訳版は以下。 8thlight.com クリーンアーキテクチャ(The Cl
Robert Martin (a.k.a. ボブおじさん) による、 The Clean Architecture の翻訳です。似たようなアーキテクチャである ヘキサゴナルアーキテクチャ も翻訳したので参考にしてください。 この記事を翻訳して公開したことは 8th Light, Inc. に報告済みです。いまのところ苦情は来ていません。 ここ数年以上、システムのアーキテクチャに関する実にさまざまなアイデアを見てきた。これには、次のものが含まれる: Hexagonal Architecture (別名 Ports and Adapters) by Alistair Cockburn。Steve FreemanとNat Pryceが、Growing Object-Oriented Software というすばらしい本で採用した。 Onion Architecture by Jeffrey Pa
この記事では、アーキテクチャを採用する理由、次にClean Architectureの概要、最後にアプリケーションの構築をしていきます。 この後詳しく見ていきますが、Clean architectureの概念は比較的シンプルでわかりやすいものだと思います。しかし実際コードに落とし込んだ時、これってどう実装すればいいのかな?と迷うことがあったので、自分の理解も深めるために実際にAPI Serverを構築していきたいと思います。 また、サーバーサイドでの採用事例をあまりみないので誰かの参考になればいいかなと思います。 サンプルコードは、Go言語です。 アーキテクチャを採用する理由 アーキテクチャに期待することは、関心の分離です。 関心の分離を正しく行うことで、次のようなメリットがあると思います。 再利用性の高い設計になり生産性が向上する コードの可読性が上がり、メンテナンスが容易になる 変化に
例として、pecoのバイナリアーカイブを取ってきて余分なファイルを作らずに/usr/local/bin/pecoに実行ファイルを置いてみよう。 例)pecoのアーカイブから実行ファイルだけ取り出してみる pecoのバイナリアーカイブの構成を確認 ちなみにpecoのアーカイブを普通に解凍すると以下の様なディレクトリとファイル構成になっている。 $ tar xf peco_linux_amd64.tar.gz $ find ./peco_linux_amd64 ./peco_linux_amd64/peco ./peco_linux_amd64/Changes pecoだけを目的の場所に取り出す方法 先ほど確認したアーカイブの内、peco_linux_amd64/peco だけを取り出して /usr/local/bin に置きたいわけだ。man tar とか確認しながら出来のが↓これ。 [[
はじめに Pods は Kubernetes の中でもっとも重要なリソースです。複数のコンテナとボリュームの組み合わせで Kubernetes におけるスケールの最小単位であり、アプリケーションコンテナは必ず Pods としてデプロイされます。 ここでは Pods の終了の流れについて詳しく扱います。Deployments の更新などで新しいバージョンのアプリケーションをデプロイするとき、既存の Pods は終了されます。このとき正しく Pods の終了処理を準備できていないと、ユーザのリクエストが正しく処理されずエラーが出力されているかもしれません。ワンオフなジョブと異なり、サーバとしてデプロイされる Pods はそれと比べて比較的寿命は長く、更新の頻度は少ないかもしれません。しかしサービスの価値をいち早くユーザに届けるに頻繁なデプロイは欠かせません。よりデプロイの頻度が高くなるほど P
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く