ブログ

揚げ春巻きに何をつけて食べるかをアンケート調査した結果についてまとめました。

ふとしたときに醤油をつける派と何もつけない派がいることを確認したので、アンケート調査してみました。 この記事ではその結果をまとめます。

なお、食べ方は複数選択可能なので同じ人が複数の食べ方を使い分けるケースがあります。 平均では1.5種類の食べ方をしているようで、半数近くは複数の食べ方を使い分けているようでした。 「何もつけない」を選んでおきながらほかの食べ方も選んだ方は「何もつけない」を選んだ方の約半数でした。

円グラフの色は各グラフで別になっているので注意してください。


食べ方人気

単純な得票数順の食べ方人気です。

これを見ると「何もつけない」がダントツのようにも見えますが、しょうゆ系をすべて足すと「何もつけない」を超えます。 「しょうゆ系」は、「しょうゆ」を含む食べ方すべてを指します。「酢系」はポン酢、酢を含む食べ方のうち、しょうゆを含まないものです。

しょうゆを優遇するのも悪いので、酢が含まれるものを「酢系」として、「しょうゆ系」に酢を含むものを入れない場合は以下です。

ついでにからし系と非からし系で分けたものが以下です。

なお、WEBで検索すると見かけるケチャップは得票ありませんでした。


地方別集計結果

次に地方別の集計結果です。 ソース、マヨネーズ、ブラックペッパーというマイナー(1票のみ)?な食べ方はいずれも関東でした。 しょうゆも酢系(酢、ポン酢)も全国区。どこでも採用されています。ポン酢は近畿、四国、九州のみでした。 ラー油は「しょうゆ+酢+ラー油」の組み合わせで、中部と近畿でのみ得票。餃子のたれですね。

北から順に載せます。


北海道。

回答者一人なので、北海道の特徴を表しているかはわかりません。というか、表していません。 「何もつけない」を選んだ方が居ない地方です。


東北地方。 回答者なし。


関東地方。一番回答者が多かったです。


中部地方。 つけるならしょうゆ必須な感じ。


近畿地方。


中国地方。 つけるならしょうゆ必須な感じ。


四国地方。 回答者一人なので、四国の特徴を表していません。


九州地方(沖縄除く)。


沖縄。 回答者なし。

この記事はGWアドベントカレンダーの8日目の記事です。

GitLabのパイプラインでdocker loginしようとすると以下のエラーで失敗しました。

 docker -l debug login -u gitlab-ci-token -p ${CI_BUILD_TOKEN} http://${CI_REGISTRY}
 Error response from daemon: Get https://xxx.xxx.xxx.xxx:4567/v2/: http: server gave HTTP response to HTTPS client

以下にあるdaemon.jsonの設定をrunnerに追加することで解決しました。 registryをHTTPS化することも考えましたが、このregistryがリバースプロキシ配下になく、一旦HTTPのままで対処しました。

Test an insecure registry

この記事はGWアドベントカレンダーの7日目の記事です。

「Ansible 実践ガイド 第3版」を読みました。 この本は、これからAnsibleを始めようとする方や少し触ってみたものの、実際の環境にどのように適用すべきか検討し始めたくらいの方に最適と思います。 ただ、既に色々とAnsibleを適用しているものの構成が複雑で保守しづらくなってしまうというような方にも向いていると思います。 具体的なプレイブックの例がいくつも紹介されており、それぞれにプレイブックのノウハウがあります。

AnsibleやYAMLについての基本的な説明から始まっていて、その後具体的なプレイブックの紹介や保守性を考慮したディレクトリ構成等の実践的な内容へと移っていきます。 プレイブックのデバッグ方法についても様々な手法が説明されており、Ansibleを利用していく上で必要なことが一通り学べるようになっていると思います。

この記事はGWアドベントカレンダーの6日目の記事です。

IaCに関連する最近読んだ本の紹介です。 読んだ順に書いていますが、Ansible実践ガイドはまだ記事を書いていないのでここで簡単に紹介します。 Ansible を自由に利用できるようになるための基礎が幅広く記載されています。そのため、「インフラCI 実践ガイド」にもAnsibleが使われていますが、この内容を理解するのにも役立ちました。 また、これから新規にプレイブックを作るときの設計のポイントも記載されています。 Linuxサーバ向けだけでなく、Windowsやネットワーク機器向けの設定についても記載されており、これらを理解することでAnsibleのエコシステムや思想の理解が深まり様々な応用ができるようになります。

この記事はGWアドベントカレンダーの5日目の記事です。

Gitlabのリポジトリにsshで接続するときはOSのgitユーザを使います。 このユーザはGitlabのユーザすべてで共用します。 そのため、全利用者の公開鍵情報をgitユーザに紐付けて管理する必要があります。

これを実現する方法として、gitユーザのauthorized_keysに全ユーザ分の公開鍵を書いておく方法がありますが、sshアクセスの度にファイルを上からスキャンし、確認する必要があり効率が悪いです。 そこでユーザ名に応じた公開鍵を返すコマンドを用意することで余計な確認を減らすことで高速化することができる仕組みがあります。

以下にGitlabでの設定の仕方が書いてありますが、OpenSSHの提供するAuthorizedKeysCommandという設定を使うことで実現できます。この設定に、公開鍵を返すコマンドを指定します。

Fast lookup of authorized SSH keys in the database

この仕組みを使うと、gitユーザのauthorized_keysに公開鍵を記載する必要がありません。

この記事はGWアドベントカレンダーの4日目の記事です。

自宅のPCにIaC環境を構築中ですが、その環境について少し説明します。

使用するツール

1台の物理Linuxサーバ上にすべての環境を構築します。 仮想マシンはVagrant + Virtual Boxで構築します。 コンテナはDockerで構築します。 構築ツールとしてAnsibleを使います。 CI/CDを実現するためのツールとしてGitlab、Gitlab Runnerを使います。

Gitlab、Gitlab Runnerの構築

GitlabとGitlab RunnerはAnsibleを使って、仮想マシンから作成します。 本番用とテスト用があり、テスト用の構築は本番用のGitlabのバックアップデータを使ってリストアすることで本番と同じデータを持つようにしています。

物理Linuxサーバの構築

OSインストール後の各種設定類はAnsibleにまとめようと思っていますが、まだできていません。

AnsibleとVagrantの連携

Ansibleのプレイブック(Gitlabのパイプラインからの呼び出しや手動実行)によって、Vagrant経由で仮想マシンを作成することがあります。 しかし、AnsibleのInventory PluginとしてはVagrant用のものが正式にはありません。そのため、作成した仮想マシンに対してプレイブックを実行するためには何らかの方法を考える必要があります。 一つはInventory PluginもしくはScriptを作ること、もう一つは作成する仮想マシン情報をあらかじめインベントリファイルに記載しておくことが考えられます。 どちらの方法でも実現できそうですが、どのようにするか検討中です。

今後の展望

  • 物理Linuxサーバ構築用のパイプライン構築
  • Kubernetesを動かす。 その上で、各種アプリケーションを動かす予定です。

この記事はGWアドベントカレンダーの3日目の記事です。

GitlabとGitlab Runnerのバージョン情報がどこにあるのか書きます。 最新バージョンが出たかどうかを知るときや、アップデートするときのバージョンを指定したい場合に具体的なバージョンを知る必要があります。 実際には使用するリポジトリのバージョン名を知る必要がありますが、開発元のリリース情報は以下にあります。 なお、GitlabとGitlab Runnerのバージョンは対応していて、同じバージョンがリリースされるみたいです。

Gitlabのリリース情報

ここにあります。

Gitlab Runnerのリリース情報

ここにあります。

この記事はGWアドベントカレンダーの2日目の記事です。

1日目の記事で、CDの対象にすべきではありませんと述べましたが、ではどのようにデプロイすべきでしょうか。 CIサーバのデプロイ方法と言っても、単なるインストール手順のことではありません。CIサーバのライフサイクルを考えた上でデプロイ手順全体を指します。 なお、本記事ではGitlabを対象に述べます。

本番用CIサーバのライフサイクル

まずは本番用のCIサーバのライフサイクルについて考えます。

  1. サーバデプロイ(OS構築)
  2. Gitlabインストール
  3. Gitlabアップデート
  4. Gitlabアップデート
  5. 以後、アップデートを繰り返す

上記のように、一度インストールした後はアップデートを繰り返します。 アップデートの際に新バージョンのインスタンスを用意すれば良いように思うかもしれませんが、GitlabはDBにデータを持っていて、異なるバージョン間でのリストアはサポートされていません。 Gitlabの場合、バックアップの仕組みを持っていますが、リストアできるバージョンは、 バックアップ取得時と同じバージョンのみがサポートされています。 そのため、アップデート済みの新インスタンスを用意してもそこへ旧バージョンのデータをリストアすることはできません。

テスト用CIサーバのライフサイクル

次にテスト用のCIサーバについて考えます。 テスト用のCIサーバは本番用と同じ操作を実施すべきなので、 テストの度に、本番用CIサーバと同じバージョンのものを再構築して動作を確認します。 ここで本番用CIサーバのバックアップデータを使ってテスト用CIサーバを構築するのがポイントです。 バックアップデータには各種プロジェクト情報やその設定値などが含まれています。これらのデータも本番用と同じものを使ってテストするのが理想的です。 したがって、テスト用CIサーバのライフサイクルは以下のようになります。

  1. サーバデプロイ(OS構築)
  2. Gitlabインストール
  3. 本番用Gitlabのバックアップデータをリストア
  4. Gitlabアップデート
  5. 以後、サーバデプロイから繰り返す

本番用CIサーバのデプロイ方法

前述のように本番用CIサーバを一度構築した後は、アップデートの適用のみを実施するようなケースを考えた場合には、その都度、アップデートを適用する方法が考えられます。 この方法の場合には、初期構築手順とアップデート手順の二つがあれば良いことになります。 これらの手順を自動化しておくことで効率的にデプロイが実現できます。 ただし、故障発生などにより最初から構築する必要があった場合に、正しく構築できるかどうか懸念が残ります。

これを解決するのがImmutable Serverです。1日目の記事でCDの対象外と述べましたが、パイプライン中でのデプロイを行わないのであれば、テスト用CIサーバを本番用CIサーバとして利用するように切り替えることも可能です。 こうすることでImmutable ServerとしてCIサーバを扱うことができます。 しかし、このような運用をする場合には注意点があります。本番用のDBバックアップを取得してから本番用CIサーバに対し何か変更があると(管理対象プロジェクトのコミット等)、それが失われる可能性があります。 つまり、利用を制限した上でバックアップから切り替えまでを完了できる必要があります。 これは多くの場合は難しいと思います。

結論

結局のところ、Immutable Serverとして扱うよりも、常にアップデートし続けるデプロイ方法の方が現実的ではないかと考えています。

明日はGitlabのバージョン情報について書く予定です。

この記事はGWアドベントカレンダーの1日目の記事です。

Infrastructure as Codeの考えでは、アプリケーションだけでなくインフラ部分(OSやミドルウェアなど)についてもCI/CDの対象として扱います。 この記事では、IaCに取り組もうと考えて最初に悩む(?)CIサーバ自身のCI/CDについて説明します。

CIサーバというのは、JenkinsやGitlabのようにコミットやプッシュを契機(trigger)に自動的にジョブを実行する機能を持つサーバのことです。 CIサーバ自身も様々な設定を持つ重要なサーバであり、管理対象です。

本記事では簡単のためにCIを自動構築と自動テストと定義します。また、CDを自動デプロイと定義します。 CI/CDのパイプラインとして自動にすべき部分や手動にすべき部分がありますが、本記事ではすべて自動で実施する場合としています。

前提

IaCの文脈で、各サーバをImmutable Serverとして扱う場合を想定しています。 環境としてテスト環境と本番環境があります。CIサーバはテスト環境と本番環境の両方にアクセスできるので、便宜上CI環境に配置されているとします。 CIとして、テスト環境の再構築とテストを実施し、CDとして本番環境の再構築とテストを実施するものとします。

CIサーバをCDの対象とすべきかどうか

CIサーバをCDの対象とするということは、CI環境のCIサーバを再構築(破棄、作成)することになります。 CIサーバをImmutable Serverとして扱うと、パイプラインの途中でCIサーバの再構築が行われるため、必ず途中で中断することになりCDの対象とすることはできません。 CIサーバをいくつものコンポーネントに分けて、一部の機能のみCDの対象とすることはできると思います。

CIサーバはImmutable Serverではない(Mutable Server)として扱うとCIサーバをCDの対象とすることができます。しかし、パイプラインを実行中のCIサーバを変更するというのは複雑で、避けるべきと思います。

したがって、CIサーバはCDの対象とすべきではないと考えます。

CIサーバをCIの対象とすべきかどうか

CIの対象(以下、CI管理対象)というのは理想的にはすべてのサーバです。したがってCIサーバもCI管理対象とすべきと考えられます。

CIサーバのテスト用インスタンスを作成し、テストを実施することは有効です。ただし、テスト用インスタンスを使って実際のパイプラインを実行してはいけません。 実際のパイプラインはテスト用のCIサーバインスタンスの再構築を含んでいたり、テスト環境や本番環境のサーバ再構築を含んでいます。実行して良いのは接続確認のような環境に変更を加えない内容のものだけです。

結論

CIサーバはCIの対象としますが、CDの対象外とします。 CIのパイプラインではテスト用インスタンスを作成し、自動テストを実行します。自動テストによってCIサーバの構築手順の妥当性を確認できます。

明日はCIサーバのデプロイ方法についての予定です。

Oracle CloudのCompute インスタンスが起動できなくなってしまいました。 正確にはインスタンスを開始させると、起動中というステータスになりますが、少し経つと今度は停止中となり、停止済みとなってしまいます。

以前は起動できたのにできなくなってしまいました。困った。。 しかもそれらしきログも出ずに原因究明ができません。 コマンドラインインタフェース(コマンドは後述)から起動してみても、開始要求は正常に行われるのでエラーになりません。

新しいインスタンスを作成用しようにも、以下のメッセージが出て作成もできません。

困った困った。。

可用性ドメインjRHI:AP-TOKYO-1-AD-1のシェイプVM.Standard.E2.1.Microの容量が不足しています。 後で再試行してください。
oci compute instance action --action=start --instance-id=

ブログ

baby and child
seiyo's memo
seiyo's mountain
seiyo's trip
インフラエンジニアの雑記

最近の記事

「インフラCI 実践ガイド」を読んだ
インフラエンジニアの雑記ブログ上
rawtherapeeでRAW現像
seiyo's memoブログ上
退職祝い
seiyo's memoブログ上