2018年12月25日火曜日

athrill を MSYS2 環境でビルドする

次の現場で tmori/athrill を使いそうなのでとりあえず環境構築までやってみる。

しかし、 athrill リポジトリに格納されているバイナリが、MinGW 用と Linux 用の 2 種類のようで、 そのまま MSYS2 環境で使えない。(何かの共有ライブラリを入れれば動くかもしれないが...)

なので、MSYS2 の gcc を使ってビルドしなおす。

ちなみに、 WSL か docker コンテナを使うのが推奨されているっぽいです。

環境

MSYS2 のベース環境アップグレード

pacman -Syu

MSYS2 MinGW 64bit を再起動してもう一度 pacman -Syu

pacman -Syu

必要パッケージのインストール

pacman -S make mingw-w64-x86_64-gcc git

athrill の取得とビルド

取得

git clone https://github.com/tmori/athrill.git

ビルド

athrill, athrill2, athrill_remote をビルドする。

cd athrill

# athrill のビルド
cd trunk/src/build/target/v850esfk3
make

# athrill2 のビルド
cd ../v850e2m
make

# athrill_remote のビルド
cd ../../../remote/remote_cui_client/
make

動作確認

athrill/bin/windows 内の athrill, athrill2, athrill_remote を叩いてみる。

$ cd PATH/TO/athrill/bin/windows

$ ./athrill
Usage:athrill -m <memory config file> [OPTION]... <load_file>
 -i                             : execute on the interaction mode. if -i is not set, execute on the background mode.
 -r                             : execute on the remote mode. this option is valid on the interaction mode.
 -t<timeout>                    : set program end time using <timeout> clocks. this option is valid on the background mode.
 -m<memory config file>         : set athrill memory configuration. rom, ram region is configured on your system.
 -d<device config file>         : set device parameter.

$ ./athrill2
Usage:athrill -m <memory config file> [OPTION]... <load_file>
 -i                             : execute on the interaction mode. if -i is not set, execute on the background mode.
 -r                             : execute on the remote mode. this option is valid on the interaction mode.
 -t<timeout>                    : set program end time using <timeout> clocks. this option is valid on the background mode.
 -m<memory config file>         : set athrill memory configuration. rom, ram region is configured on your system.
 -d<device config file>         : set device parameter.

$ ./athrill_remote
Usage: athrill_remote <athrill debug command>

ヘルプメッセージが表示されれば OK.

...athrill2 もヘルプの表記は athrill なんですね。

以上。 とりあえず実行可能な状態にはなったのでこれまで。

2018年11月27日火曜日

embulk-output-chart を作ったけどあんまりうれしくなかった話

mikoto2000/embulk-output-chart を作っていろいろ遊ぼうとしたけれど、そもそも機能が足りないという感じであんまりうれしくなかった。

環境

やろうとしたこと

vim/vim-history リポジトリから、日ごとのコミット数をグラフにした(したかった)。

作業記録

概要としてはこんな感じ。

  1. vim-history リポジトリをクローン
  2. git log を xml として出力
  3. xml から sqlite に取り込み
  4. sqlite に集計クエリを投げつつチャート表示

vim-history リポジトリをクローン

git clone https://github.com/vim/vim-history.git
cd vim-history

git log を xml として出力

メッセージのエスケープ問題を回避するため、 xml の CDATA を活用することにした。

練習用に、今回使わない情報も入れている。 必要に応じて追加削除修正する感じで。

date は、書いた時の日付ということで、 author date のほうを取得している。

echo "<xml>"$(git log --pretty=format:'<commit><hash><![CDATA[%H]]></hash><subject><![CDATA[%f]]></subject><body><![CDATA[%b]]></body><author><![CDATA[%aN]]></author><commiter><![CDATA[%cN]]></commiter><author><![CDATA[%aN]]></author><date><![CDATA[%aI]]></date></commit>')"</xml>" > history_tmp.xml

xml から sqlite に取り込み

必要プラグインのインストール

embulk.bat gem install embulk-parser-xml embulk-output-jdbc

sqlite 用 jar ファイルのダウンロード

Maven リポジトリから sqlite-jdbc-3.25.2.jar をダウンロードしてカレントディレクトリに配置。

設定ファイル記述

in:
  type: file
  path_prefix: ./history_tmp.xml
  parser:
    type: xpath
    root: //commit
    schema:
      - {path: hash, name: hash, type: string}
      - {path: author, name: author, type: string}
      - {path: date, name: date, type: string, timestamp_format: "%Y-%m-%dT%H:%M:%S.%L%z", timezone: "+0000"}
      - {path: body, name: body, type: string}
out:
  type: jdbc
  driver_path: './sqlite-jdbc-3.25.2.jar'
  driver_class: 'org.sqlite.JDBC'
  url: 'jdbc:sqlite:vim_history.sqlite3'
  table: vim_history
  mode: 'replace'
  create_table_constraint: PRIMARY KEY(hash)

embulk 実行

embulk.bat run .\xml2sqlite.yml

sqlite に集計クエリを投げつつチャート表示

必要プラグインのインストール

embulk.bat gem install embulk-input-jdbc

embulk-output-chart のクローン

gem 化されていないので、 git clone で持ってきてビルドする。

git clone https://github.com/mikoto2000/embulk-output-chart.git ..\embulk-output-chart
cd ..\embulk-output-chart
.\gradlew.bat package
cd ..\vim-history

設定ファイル記述

exec:
  max_threads: 1
  min_output_tasks: 1
out:
  type: chart
  chart_type: LINE
  x_axis_name: Date
  x_axis_type: NUMBER
  y_axis_name: Commit
  y_axis_type: NUMBER
  serieses:
    - {name: "commit count", x: d_date, y: count}
in:
  type: jdbc
  driver_path: './sqlite-jdbc-3.25.2.jar'
  driver_class: 'org.sqlite.JDBC'
  url: 'jdbc:sqlite:vim_history.sqlite3'
  query: select cast(strftime('%s', date(date), 'utc') as long) as d_date, count(date) as count from vim_history group by d_date;
  column_options:
    d_date:
      value_type: long
    count:
      value_type: long

チャート表示実行

..\..\embulk\embulk.bat run -L ..\embulk-output-chart .\sqlite2chart.yml

はい。

まー、そうですね...。残念ですねという感じで。

今後に向けて

  • Date Axis が欲しい
    • カスタムラベルとかでごまかせるかな?
  • 表示範囲調整機能が欲しい
  • 集計が SQL 任せなのつらい
  • 画像保存できないとダメでは???

以上。ぼちぼちやっていきましょう。(そもそもチャート表示して嬉しいの?ということは考えてはいけない)

VimConf2018 に参加しました

VimConf 2018 のメモ書きです。

基本的な情報は公式ページ(VimConf 2018)を参照。

今回は Vim 本体の中身の話が印象に残りました。

変なまとめ方になっちゃったけど、以下、印象に残ったもののメモ書きです。

メモ書き

  • 未来の話
    • Vim のプラットフォーム化
      • プラグインプラットフォームとして、プラグイン開発者に便利な機能を追加していく
    • Vim script 高速化
      • Vim script 自体を早くする方針で検討していく
        • Vim script のコンパイル?
      • 検討したけど採用しない(つもり)の話が面白かった
        • 別言語化(if_xxx)
        • マルチスレッド化
    • Text Properties
      • 「任意の 1 行だけ抜き出してもちゃんとハイライトできるデータ構造にする」という感じの理解だったけどあっているのかな?
      • ばかでかい XML とかよく開くのでそういったものが上手くハイライトできるようになってくれると嬉しいですね
    • Support DRCS Sixel on :terminal
      • mattn さんの Suggestion
      • これすごく欲しいと思った
      • mlterm on android とかで、Markdown や PlantUML のような描画用 SDL のレンダリング結果を確認したいときとかあるんですよ
        • Sixel 対応来てくれると Vim 滞在率が上がって嬉しい
  • 現在の話
    • Oni
      • 内臓ブラウザとスニークモードの組み合わせが Vimperator を思い出させてくれた
        • 「内臓ブラウザとのやり取りが簡単なら Vimperator 代替になるのでは???」と思った
      • 帰ってから少し触った
        • Tutorial と Achievement の組み合わせが素敵だった
        • :Browser で内臓ブラウザが立ち上がらなかった
      • 今使っている .vimrc とマッチしない操作感の場所があるので、少しずつ試していきたい
    • 自作プラグイン書き直さなきゃ...
    • :Termdebug
      • Vim ソースコードウォーキングのお供にも良さそう
      • 入門として、Linda_ppさんの発表にあったあのシーケンス図をたどるのに使ってみるとか良さそう?(たどれるのは getchar.c までだけれど)
    • プラグイン系
      • w0rp/ale
      • ggreer/the_silver_searcher の話で mattnjvgrep を思い出したので、比較して導入する
      • eclipse/eclipse.jdt.ls
        • 懇親会で教えてもらったもの。どうにかして Vim で Java を書きたい...
      • 性能確認
        • :help profile
        • :help --startuptime
      • oldfiles_selector.vim を作る
        • :help oldfiles
      • :help ins-completions
        • 補完とスニペット、自作したい

私的 TODO

以下、やっていきます。

おわりに

やりたいことがもりもり出てきました。 今回補給した情報とやる気でやっていきたいと思います。

VimConf 準備会スタッフのみなさま、おつかれさまでした。そして、ありがとうございました。

2018年11月19日月曜日

Helix のキーカスタマイズを行う

環境

  • OS: Windows 10 Pro
  • Msys2

環境構築

Msys2 環境アップデート

pacman -Syu

QMK ファームウェアプロジェクトをクローン

git clone https://github.com/qmk/qmk_firmware.git

ビルド環境構築

cd PATH/TO/qmk_firmware
./util/msys2_install.sh
source ~/qmk_utils/activate_msys2.sh

インストール中は、ひたすら 'a' とか 'y' とか入力していく。

既存キーマップの動作確認

既存 JIS キーマップをビルド

cd PATH/TO/qmk_firmware
make helix:five_rows_jis

ファームウェア焼きこみ

cd PATH/TO/qmk_firmware
make helix:five_rows_jis:avrdude

左右両方に焼きこんだらとりあえず動いた。

キーマップのカスタマイズ

five_rows_jis をベースにキーマップをカスタマイズしていく。

キーマップ設定ファイルコピー

同梱されているキーマップ five_rows_jis ベースにキーマップを作っていくので、同ディレクトリにコピーを作る。

cd PATH/TO/qmk_firmware
cd keyboards/helix/rev2/keymaps/
cp -r five_rows_jis/ mikoto2000_five_rows_jis

キーマップ設定変更

今回は keymap.c, rules.mk を修正。 公開する場合にはドキュメントの変更も忘れずに。

vim keymap.c
vim rules.mk
vim readme.md
vim readme_jp.md

最終的にこんな差分になった。

差分

カスタマイズしたファームウェアを焼きこむ

cd PATH/TO/qmk_firmware
make helix:mikoto2000_five_rows_jis:avrdude

以上。

2018年11月11日日曜日

Helix キーボードキットのはんだ付けの様子を撮ったから見てくれ

そしてやさしい方はアドバイスとかしてください。

背景

Helix キーボードキット | 遊舎工房を買った。

そしてこうなった...

キットを買いなおして右手側を作るついでに、はんだ付けの様子を撮影したので公開。

ちなみに、どうしてもはんだが溶けないので、はんだごての温度設定を MAX にして作業していました。 とりあえず、こんな適当でも動くものが組み立てられるということで。

はんだ付け以外の箇所はビルドガイドを参照。

はんだ動画たち

PCBの準備

パーツ実装 - ダイオード

パーツ実装 - TRRS ジャック

パーツ実装 - リセットスイッチ

Pro Micro

PCB は壊したけど Pro Micro は無事だったので省略。

パーツ実装 - OLEDモジュール

パーツ実装 - Underglow用テープLED

パーツ実装 - キースイッチ

結果

そしてこうなりました。

その他

キートップとキースイッチはこちらから購入しました。XDA Blank Keycap (2Pieces/Gray) と Gateron MX Switch Blue 3Pin (5PCs) 。

TALP KEYBOARD

使用した道具たち

この辺のものを使用しました。

2018年10月16日火曜日

Eclipse のヘッドレスアプリケーションを作る

Eclipse のヘッドレスアプリケーションプラグインを作り、 コマンドラインからプラグインの処理を呼び出す。

本当は Java11 でやりたかったのだけれど、 「エクスポートした jar に class ファイルが格納されない問題」が解決できなかった。

なので、Java8 で Eclipse 4.9 を動かしている。

環境

  • OS: Windows 10 Pro
  • Java: java version "1.8.0_151"
  • Eclipse: Version: 2018-09 (4.9.0)
    • for Commiters

Eclipse の準備

Eclipse のダウンロードと展開

Enabling Open Innovation & Collaboration | The Eclipse Foundation からダウンロードする。

  1. Download -> Tool Platforms セクションの Download Packages
  2. Eclipse IDE for Eclipse CommittersWindows 64-bit
  3. Download ボタンからダウンロード
  4. ダウンロードした zip ファイルを適当な場所に展開

Eclipse を起動する Java の指定

僕の作業用 Windows は、デフォルトの Java を 11 にしている。 最初に説明したとおり、 11 だとうまくエクスポートができない。 そのため、Java 8 で Eclipse が動くように修正する。

eclipse.ini をテキストエディタで開き、 -vmargs の直前に、次の 2 行を追加する。 (\PATH\TO\JDK1.8.0\bin\javaw.exe は自分の環境に合わせて書き換える)

-vm
\PATH\TO\JDK1.8.0\bin\javaw.exe

プラグイン作成

eclipse を起動し、プラグインを開発していく。

プラグインプロジェクトの作成

  1. Plug-in Development パースペクティブを開く
  2. File -> New -> Plug-in Project
  3. 基本情報設定 -> Next
    • Project name: HeadlessApplication
  4. コンテント情報入力 -> Next
    • Options のチェックを全部外す
    • Rich Client Application 内のラジオボタンで Yes を選択
  5. テンプレートの選択 -> Finish
    • Headless Hello RCP を選択

この状態で、「呼び出すと Hello RCP World! と標準出力されるヘッドレスアプリケーション」が生成される。

プラグインのエクスポート

  1. プロジェクト右クリック -> Export
  2. Deployable plug-ins and fragments を選択して Next
  3. エクスポート設定 -> Finish
    • HeadlessApplication にチェックを入れる
    • Destination タブの Directory に、出力先ディレクトリを入力

Directory に指定したディレクトリ内に、 plugins ディレクトリが作成され、 その中にプラグインの jar ファイルが格納される。

動作確認

プラグインのインストール

「プラグインのエクスポート」で作成された jar ファイルを、 eclipse の dropins ディレクトリにコピーする。それだけ。 (本当はいろいろ作法があるらしい?未調査。)

動作確認

標準出力を確認したいので、 java.exe を使って実行する。

eclipsec.exe -nosplash -application HeadlessApplication.application -vm \PATH\TO\JDK1.8.0\bin\java.exe

下記出力が得られれば成功。

org.eclipse.m2e.logback.configuration: The org.eclipse.m2e.logback.configuration bundle was activated before the state location was initialized.  Will retry after the state location is initialized.
Hello RCP World!

あとはこれにお好きな処理を追加していくだけ。

環境に応じた Preference の値を流し込むとか、 Eclipse 操作のオートメーションとかできるといいなぁ...。

以上。

参考資料

2018年10月14日日曜日

Java 11 + Spring Boot 2 + Spring Data JPA で PostgreSQL にアクセスする

こんな感じのことをします。(察して...)

DB アクセスのエッセンスに注目したかったので、 CLI アプリとして作ります。

環境

  • OS: Windows 10 Pro
  • Java: openjdk version "11" 2018-09-25
  • Docker: Docker version 18.06.1-ce, build e68fc7a

依存定義

次の jar を依存関係として定義した。

Java9(11?) からの変更の影響により、 jaxb-apijavassist を明示的に追加する必要が出てきたらしい。

dependencies {
    compile("org.springframework.boot:spring-boot-starter:2.0.5.RELEASE")
    compile('org.springframework.boot:spring-boot-starter-data-jpa:2.0.5.RELEASE')
    runtime('org.postgresql:postgresql')

    // https://mvnrepository.com/artifact/javax.xml.bind/jaxb-api
    compile group: 'javax.xml.bind', name: 'jaxb-api', version: '2.3.1'

    // https://mvnrepository.com/artifact/org.javassist/javassist
    compile group: 'org.javassist', name: 'javassist', version: '3.23.1-GA'
}

PostgreSQL 環境の構築

構成

  • サーバー: PostgreSQL
  • DB: postgres

こんな感じで構築する。

               List of relations
 Schema |      Name      |   Type   |  Owner
--------+----------------+----------+----------
 public | message        | table    | postgres
 public | message_id_seq | sequence | postgres
(2 rows)
                                    Table "public.message"
 Column  |          Type          | Collation | Nullable |               Defaul
t
---------+------------------------+-----------+----------+-------------------------------------
 id      | integer                |           | not null | nextval('message_id_seq'::regclass)
 message | character varying(255) |           | not null |
Indexes:
    "message_pkey" PRIMARY KEY, btree (id)

環境を作る

Docker オフィシャルの PostgreSQL イメージを使って作成する。

Docker オフィシャルの PostgreSQL イメージは、コンテナ起動時に指定した sql を実行する機能があるので、その仕組みを使ってデータを入れる。

初期データ作成 sql

$(pwd)/schema/schema.sql を作成。

DROP TABLE IF EXISTS message;
DROP SEQUENCE IF EXISTS message_id_seq;

CREATE SEQUENCE message_id_seq START WITH 1 INCREMENT BY 1;

CREATE TABLE message (
  id INTEGER DEFAULT nextval('message_id_seq') PRIMARY KEY,
  message VARCHAR(255) NOT NULL
);

INSERT INTO message(message)
    VALUES
        ('テスト1'),
        ('テスト2');

コンテナ起動 + データ作成

次のコマンドで、 PostgreSQL サーバー起動と、前述の初期データの作成が完了する。

docker run -it --rm --name postgres -v "$(pwd)/schema:/docker-entrypoint-initdb.d" -p 5432:5432 postgres

プログラミング

エンティティの作成

まず、 DB から取得するレコードを表す Bean を作成する。

  • 今回は、 idmessage を取得したいので、それらをフィールドに持つ Bean を作る
  • アノテーション @Entity を付ける
  • プライマリキーに @Id アノテーションを付ける
  • id はシーケンスによる自動採番なので、それ関係のアノテーションを付ける
    • @SequenceGenerator
    • @GeneratedValue
package gs.postgres;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;
import javax.persistence.SequenceGenerator;

/**
 * Message
 */
@Entity
@SequenceGenerator(name = "message_id_seq", sequenceName = "message_id_seq", allocationSize = 1, initialValue = 1)
public class Message {
    @Id
    @GeneratedValue(generator="message_id_seq")
    private Long id;

    private String message;

    public Long getId() {
        return this.id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public String getMessage() {
        return this.message;
    }

    public void setMessage(String message) {
        this.message = message;
    }

    @Override
    public String toString() {
        return String.format("id:%d, message=%s", this.id, this.message);
    }
}

リポジトリインターフェースを作成

DB への操作を抽象化してくれるやつを作る。

JpaRepository を継承したインターフェース定義だけ定義すれば、 Spring が良しなに実装を作ってくれるらしい。

継承する JpaRepository は、 JpaRepository<エンティティの型, エンティティのプライマリキーの型> とする。

package gs.postgres;

import org.springframework.data.jpa.repository.JpaRepository;

/**
 * MessageRepository
 */
public interface MessageRepository extends JpaRepository<Message, Long> {
}

DB にアクセスするプログラムを作る

情報取得と挿入、標準出力するプログラムを作成する。

  • repo フィールドに @Autowired アノテーションを付けているため、 Spring によって自動で MessageRepository のインスタンス化と代入が行われる。
    • MessageRepository は、SpringApplication.run(App.class, args) をした時点で、よしなに実装が作られるみたい
  • repoJpaRepository (Spring Data JPA 2.1.0.RELEASE API) のインターフェースが実装されているので、これを使って DB 操作ができる
package gs.postgres;

import java.util.List;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.CommandLineRunner;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.data.domain.Sort;

@SpringBootApplication
public class App implements CommandLineRunner {

    // `SpringApplication.run` で実行した時点で、
    // よしなに `MessageRepository` クラスが注入されるらしい。
    @Autowired
    private MessageRepository repo;

    public static void main(String[] args) {
        SpringApplication.run(App.class, args);
    }

    /**
     * App 主処理
     *
     * 1. メッセージを全件取得して標準出力
     * 2. メッセージインサート
     * 3. メッセージを全件取得して標準出力
     *
     */
    @Override
    public void run(String... args) {

        // DB(postgres/message) から全件取得する
        List<Message> messages1 = repo.findAll(new Sort(Sort.Direction.ASC, "id"));

        // 取得した全件標準出力
        for (Message message : messages1) {
            System.out.println(message);
        }

        // 新規メッセージのインサート
        // ID はシーケンスからの自動採番なので null のままで良い
        Message insertMessage = new Message();
        insertMessage.setMessage("インサートメッセージ");
        repo.save(insertMessage);

        System.out.println("Message added.");

        // もう一度全件取得する
        List<Message> messages2 = repo.findAll(new Sort(Sort.Direction.ASC, "id"));

        // 取得した全件標準出力
        for (Message message : messages2) {
            System.out.println(message);
        }
    }
}

アプリの設定

src/main/resourcesapplication.propertieshibernate.properties を作成する。

application.properties

PostgreSQL に接続するための情報を記述。

spring.datasource.driver-class-name=org.postgresql.Driver
spring.datasource.url=jdbc:postgresql://localhost:5432/postgres
spring.datasource.username=postgres
spring.datasource.password=

hibernate.properties

hibernate.properties はこのエラー対策

hibernate.jdbc.lob.non_contextual_creation = true

動作確認

ここまで作ったらあとは gradle run するだけ。

gradle run

以下のような感じで取得とインサートが出来ていることが確認できる。

> gradle run

> Task :run

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::        (v2.0.5.RELEASE)

...(略)...

2018-10-14 14:36:00.877  INFO 25552 --- [           main] o.h.h.i.QueryTranslatorFactoryInitiator  : HHH000397: Using ASTQueryTranslatorFactory
id:1, message=テスト1
id:2, message=テスト2
Message added.
id:1, message=テスト1
id:2, message=テスト2
id:3, message=インサートメッセージ

...(略)...

2018-10-14 14:36:01.047  INFO 25552 --- [       Thread-2] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Shutdown completed.

BUILD SUCCESSFUL in 5s
3 actionable tasks: 1 executed, 2 up-to-date

完成品はこちら

以上。

参考資料

2018年10月12日金曜日

Terraform で AWS の EC2 インスタンスを作って SSH 接続するまでをやってみる

Installing Terraform - Terraform by HashiCorp を見ながらやってみる。

環境・前提

Docker for Windows で hashicorp/terraform のイメージを使う。

  • Host OS: Windows 10 Pro
  • image: hashicorp/terraform:0.11.8
  • docker: Docker version 18.06.1-ce, build e68fc7a

必要パッケージのインストール

docker pull するだけ。

docker pull hashicorp/terraform:0.11.8

AWS の環境設定

AWS を Terraform で操作するための準備。 下記 3 つを作成する。

  • Terraform で AWS リソースをいじれるようにするための設定
    • グループ
    • ユーザー
  • EC2 インスタンスに SSH ログインできるようにするための下準備
    • EC2 のセキュリティグループ

ポリシーは、 AWS デフォルトポリシーのひとつを使用するので作成しなくてよい。

グループの作成

Terraform の aws_instance に必要な権限の記載が見つからなかったので、 AmazonEC2FullAccess を使用する。

  1. AWS マネジメントコンソール -> サービス -> IAM -> グループ
  2. 新しいグループの作成 -> グループ名入力 -> 次のステップ
    1. グループ名: Terraform
  3. AmazonEC2FullAccess のポリシーをアタッチ -> 次のステップ
  4. グループの作成

ユーザーの作成

  1. AWS マネジメントコンソール -> サービス -> IAM -> ユーザー
  2. ユーザーを追加 -> ユーザー名、アクセスの種類を入力 -> 次のステップ
    1. ユーザー名: mikoto2000-terraform
    2. アクセスの種類: プログラムによるアクセス
  3. アクセス許可の設定 -> 次のステップ
    1. ユーザーをグループに追加を選択
    2. グループ Terraform を追加する
  4. ユーザーの作成

作成直後に表示される、 アクセスキー IDシークレットアクセスキー をメモしておく。

EC2 セキュリティグループの作成

「どこからでも SSH アクセスしていいよ」というセキュリティグループを作る。

  1. AWS マネジメントコンソール -> サービス -> EC2 -> セキュリティグループ
  2. セキュリティグループの作成 -> セキュリティグループ名、説明、インバウンドルールを入力 -> 作成
    1. セキュリティグループ名: ssh
    2. 説明: Publish SSH port.
    3. インバウンド
      • タイプ: SSH
      • ソース: 任意の場所

Terraform 設定ファイルの作成

Getting Start の例 に、いくつか修正を加える。

  • 変数を使用
  • SSH のための設定を追加
    • key_name を追加
    • security_groups を追加

tf ファイル作成

getting_start.tf という名前で作成。

variable access_key {}
variable secret_key {}
variable key_name {}

provider "aws" {
  access_key = "${var.access_key}"
  secret_key = "${var.secret_key}"
  region     = "us-east-1"
}

resource "aws_instance" "example" {
  ami             = "ami-2757f631"
  key_name        = "${var.key_name}"
  instance_type   = "t2.micro"
  security_groups = ["ssh"]
}
  • Getting Start では指定していないが、 provider/version を指定することで、使用する provider のバージョンを固定できるようだ。(詳細はここを参照)
  • aws_instance/ami に、 Packer で作ったイメージを指定するなど、良い感じにイメージを選べばよいみたい。
  • SSH ログインできるように、下記を設定
    • /aws_instance/key_name : 前回作ったキーペアの名前を指定
    • /aws_instance/security_groups : 「EC2 セキュリティグループの作成」で作成したセキュリティグループ名を指定

変数ファイル作成

variables.tfvars という名前で作成。

AWS_ACCESS_KEY, AWS_SECRET_KEY はそれぞれ、ユーザーの作成 で確認した アクセスキー IDシークレットアクセスキー を設定する。

access_key = "AWS_ACCESS_KEY"
secret_key = "AWS_SECRET_KEY"
key_name   = "mikoto2000"

インスタンス作成

ざっくりいうと、下記 3 フェーズで、それぞれ terraform コマンドを叩いて実行していく。

  1. 初期化
  2. 計画の確認と適用
  3. 確認

以降は、 docker コンテナの中で作業していく。

docker run -v "\PATH\TO\WORK_DIR:/work" --workdir "/work" --entrypoint='' -it --rm hashicorp/terraform:0.11.8 /bin/sh

初期化

必要なプラグインのダウンロードとプロバイダの状態を記録するファイルの初期化処理を行う。

terraform init

計画の確認と適用

次のコマンドを実行すると、 terraform の実行計画が表示されるので、受け入れる場合には yes と打って Enter.

terraform apply -var-file=./variables.tfvars

動作確認

AWS に反映できていることを確認する。

マネジメントコンソールで確認

  1. AWS マネジメントコンソール -> サービス -> EC2 -> インスタンス
  2. 条件通りのインスタンスが作成されているかを確認する

SSH 接続

インスタンス情報の パブリック DNS (IPv4) のアドレスに、 Tera Term Pro で接続する。

  1. User name: ubuntu
  2. Use RSA/DSA/ECDSA/ED25519 key to log in を選択し、鍵に ~/.ssh/mikoto2000.pem を指定

はい成功。

後片付け

terraform destroy コマンドで、作成したリソースを削除できる。

terraform destroy -var-file=./variables.tfvars

ASW でインスタンスが削除されているのが確認出来たら OK.

参考資料

2018年10月7日日曜日

AWS を初めて触る状態から Packer を使ってインスタンスを作成してログインするまでをやってみる

Getting Start を見ながらやってみる。

環境・前提

Docker for Windows で hashicorp/packer のイメージを使う。

  • Host OS: Windows 10 Pro
  • image: hashicorp/packer:1.3.1
  • docker: Docker version 18.06.1-ce, build e68fc7a

AWS のアカウントは、作成だけした状態からスタート。

必要パッケージのインストール

docker pull するだけ。

docker pull hashicorp/packer:1.3.1

AWS の環境設定

Packer で AWS のリソースをいじるためには、 いろいろと権限が必要。

下記 3 つを作成する。

  • ポリシー
  • グループ
  • ユーザー

ポリシーの作成

必要な権限は Amazon AMI Builder のドキュメントに記載されている ので、この JSON をコピーしてポリシーを作る。

  1. AWS マネジメントコンソール -> サービス -> IAM -> ポリシー
  2. ポリシーの作成 -> JSON タブを開く -> 前述の JSON 定義を貼り付け -> Review policy
  3. 名前、説明を記述 -> Create policy
    1. ポリシー名: packer-basic

グループの作成

  1. AWS マネジメントコンソール -> サービス -> IAM -> グループ
  2. 新しいグループの作成 -> グループ名入力 -> 次のステップ
    1. グループ名: Packer
  3. packer-basic のポリシーをアタッチ -> 次のステップ
  4. グループの作成

ユーザーの作成

  1. AWS マネジメントコンソール -> サービス -> IAM -> ユーザー
  2. ユーザーを追加 -> ユーザー名、アクセスの種類を入力 -> 次のステップ
    1. ユーザー名: mikoto2000-packer
    2. アクセスの種類: プログラムによるアクセス
  3. アクセス許可の設定 -> 次のステップ
    1. ユーザーをグループに追加を選択
    2. グループ Packer を追加する
  4. ユーザーの作成

作成直後に表示される、 アクセスキー IDシークレットアクセスキー をメモしておく。

イメージ作成用テンプレートの作成

ベーステンプレートファイルの作成

とりあえず、 Getting Start の JSON をまるっとコピーし、 getting_start.json として保存。

{
  "variables": {
    "aws_access_key": "",
    "aws_secret_key": ""
  },
  "builders": [{
    "type": "amazon-ebs",
    "access_key": "{{user `aws_access_key`}}",
    "secret_key": "{{user `aws_secret_key`}}",
    "region": "us-east-1",
    "source_ami_filter": {
      "filters": {
      "virtualization-type": "hvm",
      "name": "ubuntu/images/*ubuntu-xenial-16.04-amd64-server-*",
      "root-device-type": "ebs"
      },
      "owners": ["099720109477"],
      "most_recent": true
    },
    "instance_type": "t2.micro",
    "ssh_username": "ubuntu",
    "ami_name": "packer-example {{timestamp}}"
  }]
}
  • 他のイメージを元に作成したい場合には、 builders/source_ami_filter/filters/ の各項目に、 AWS マネジメントコンソール -> AMI からイメージを検索したときに出てくる情報を入れればよいらしい。
  • 別リージョンに作成したい場合は、builders/regionここ のどれかにすればよいらしい。

変数ファイルの作成

キー類をハードコードするのが嫌だったのでやり方を探したら、 別 JSON に記載する方法 があったのでそれを採用することにした。

AWS_ACCESS_KEY, AWS_SECRET_KEY はそれぞれ、ユーザーの作成 で確認した アクセスキー IDシークレットアクセスキー を設定する。

{
  "aws_access_key": "AWS_ACCESS_KEY",
  "aws_secret_key": "AWS_SECRET_KEY"
}

作ったファイルの検証

hashicorp/Packe のイメージを起動。

docker run -v "\PATH\TO\WORK_DIR:/work" --workdir "/work" --entrypoint='' -it --rm hashicorp/packer:1.3.1 /bin/bash

コンテナ内で次のコマンドを実行する。

packer validate -var-file=./variables.json getting_start.json

成功なら Template validated successfully. と表示される。

イメージのビルド

引き続き、コンテナ内で次のコマンドを実行する。

packer build -var-file=./variables.json getting_start.json

最終的に下記のような成功ログが表示されるはず。 数分かかった。

==> Builds finished. The artifacts of successful builds are:
--> amazon-ebs: AMIs were created:
us-east-1: ami-0acbfa688dc2e0b4b
  1. Packer Builder というインスタンスを作る
  2. source_ami_filter の条件に引っかかったものを取得・展開
  3. 「2.」でとってきたものをイメージ化

みたいなことをしているっぽい。

完成したイメージは、 AWS マネジメントコンソール -> サービス -> EC2 -> AMI で確認できる。

動作確認

作成したイメージからインスタンス作成ができることを確認する。

インスタンス作成

  1. AWS マネジメントコンソール -> サービス -> EC2 -> インスタンス
  2. インスタンスの作成
    1. マイ AMI -> 今回作った AMI を選択
    2. t2.small を選択 -> 確認と作成
    3. 作成
    4. キーペアの作成
      1. 新しいキーペアの作成を選択
        • キーペア名: mikoto2000
      2. キーペアのダウンロード
        • ~/.ssh/mikoto2000.pem に保存
    5. インスタンスの作成

数分待つと、 AWS マネジメントコンソール -> サービス -> EC2 -> インスタンス に今作ったインスタンスが作成され、ステータスチェックがパスしていることが確認できる。

SSH 接続

インスタンス情報の パブリック DNS (IPv4) のアドレスに、 Tera Term Pro で接続する。

  1. User name: ubuntu
  2. Use RSA/DSA/ECDSA/ED25519 key to log in を選択し、鍵に ~/.ssh/mikoto2000.pem を指定

はい。

このあと、イメージのカスタマイズが必要であれば provisioners でがちゃがちゃする感じなのかな?

後片付け

これまでの手順で、インスタンス・AMI・スナップショットが作成されているので、それぞれ削除すること。 削除しないと課金されるはず。

それぞれは次の場所で削除可能。

  • インスタンス : AWS マネジメントコンソール -> サービス -> EC2 -> インスタンス
  • AMI : AWS マネジメントコンソール -> サービス -> EC2 -> AMI
  • スナップショット : AWS マネジメントコンソール -> サービス -> EC2 -> スナップショット

以上。

参考資料

2018年9月12日水曜日

QEMU でエミュレートした Raspberry Pi 3 のシステムレジスタを確認した

前回からだいぶたってしまったが、 QEMU が Raspberry Pi 3 のエミュレートに対応したので復活。

システムレジスタの値を確認するコードを作成したので、仕様書と突き合わせていく。

実行結果

core id 以外はすべて 2 進数表記なので 0x でなく 0b 表記でないといけなかったですね…。

qemu-system-aarch64 -kernel ./kernel8.elf -serial null -serial mon:stdio -nographic -machine raspi3
core id: 0.
currentel: 0x1100.
nzcv: 0x1100000000000000000000000000000.
daif: 0x1111000000.
spsr_el1: 0x0.
spsr_el2: 0x0.
spsr_el3: 0x0.
midr_el1: 0x1000001000011111101000000110100.
revidr_el1: 0x0.
id_aa64pfr0_el1: 0x10001000100010.
id_aa64isar0_el1: 0x10001000100100000.
isr_el1: 0x0.

仕様書との突合せ

CurrentEL

記載箇所: Architecture Reference Manual - C5.2.1 CurrentEL, Current Exception Level

EL
0b00 EL0
0b01 EL1
0b10 EL2
0b11 EL3

ということで、 EL3 で動いているということがわかった。

NZCV

記載箇所: Architecture Reference Manual - C5.2.10 NZCV, Condition Flags

ラベル 意味
V Overflow condition flag. (1: 直前の計算がオーバーフローした, 0: 直前の計算がオーバーフローしていない)
C Carry condition flag. (1: 直前の計算で桁上がりした, 0: 直前の計算で桁上がりしていない)
Z Zero condition flag. (1: 直前の計算結果がゼロだった, 0: 直前の計算結果がゼロでなかった)
N Negative condition flag. (1: 直前の計算結果を符号付として解釈した時に、それが負数だった, 0:直前の計算結果を符号付として解釈した時に、それが負数でなかった)

29, 30 が 1 なので、この場合、Carry Condition flag と Zero condition flag が立っているのがわかる。

DAIF

記載箇所: Architecture Reference Manual - C5.2.2 DAIF, Interrupt Mask Bits

ラベル 意味
D Debug exceptions mask.
A SError interrupt Process state mask.
I IRQ mask.
F FIQ mask.

DAIF が全部マスクされていますね。

spsr_el1 - 3

EL1 から EL3 まで全部同じで全部 0。 例外一度も飛ばしていませんからね。

MIDR_EL1

ブロック 意味
Implementer 0x41 ARM Limited
Variant 0x0 製品のバリエーション判定に使えるが、 QEMU の場合は 0x0 固定らしい?
Architecture 0b1111 ID_* レジスタで個別に識別されるという意味
PartNum 0x0D03 製品番号?
Revision 0b0100 デバイスのリビジョン番号

revidr_el1

実装定義。 QEMU の場合は全部ゼロ。

id_aa64pfr0_el1

ブロック 意味
EL0 0b0010 Aarch64 または Aarch32 で実行ができる
EL1 0b0010 Aarch64 または Aarch32 で実行ができる
EL2 0b0010 Aarch64 または Aarch32 で実行ができる
EL3 0b0010 Aarch64 または Aarch32 で実行ができる
FP 0b0000 浮動小数点サポート(詳細は仕様書にて)
AdvSIMD 0b0000 SIMD サポート(詳細は仕様書にて)
GIC 0b0000 GIC Interface 未サポート
RAS 0b0000 RAS 未サポート
SVE 0b0000 SVE 未実装

oh…, GIC 未サポートなのか…。

id_aa64isar0_el1

ブロック 意味
AES 0b0010 AESE, AESD, AESMC, AESIMC, PMULL/PMULL2
SHA1 0b0001 SHA1C, SHA1P, SHA1M, SHA1H, SHA1SU0, SHA1SU1
SHA2 0b0001 SHA256H, SHA256H2, SHA256SU0, SHA256SU1, SHA512, SHA512H, SHA512H2, SHA512U0, SHA512SU1
CRC32 0b0001 CRC32B, CRC32H, CRC32W, CRC32X, CRC32CB, CRC32CH, CRC32CW, CRC32CX
Atomic 0b0000 Atomic 未サポート
RDM 0b0000 RDM 未サポート
SHA3 0b0000 SHA3 未サポート
SM3 0b0000 SM3 未サポート
SM4 0b0000 SM4 未サポート
DP 0b0000 DP 未サポート
FHM 0b0000 FHM 未サポート

とのこと。

isr_el1

ブロック 意味
F 0b0 FIQ pending bit.(0: No pending, 1: pending)
I 0b0 IRQ pending bit.(0: No pending, 1: pending)
A 0b0 SError pending bit.(0: No pending, 1: pending)

ペンディングとは?

まとめ

以上。 GIC 未サポートというのは予想外だったけれどまぁこんなものでしょうか?

参考資料

2018年8月18日土曜日

MSYS2 で openFrameworks の環境を整える

環境

  • OS: Windows10 Pro
  • MSYS2 インストール直後

作業ディレクトリは ~/project/of_study

基本的には IDE setup guides - MSYS2 - openFrameworksJp の通りにやっていくだけ。

※ 詳しいことはわからないが、MSYS2 MinGW 32-bit で実行しないといけないようだ。(64-bit でやったら make でエラーになった)

MSYS2 環境の準備

環境のアップデート

シェルを再起動して更新続行

ここまでが openframeworks に書いてある手順なのだけれど、 curl とかがまともに動かないっぽいのでシステム全体をアップデート。

ダウンロードした openFrameworks のパッケージを展開するために unzip コマンドをインストール。

必要なファイルのダウンロード・展開

ライブラリのビルド

サンプルのビルド

必要なパスを通す

mingw32 の bin が見つかるようにパスを通す。

いつも mingw32 使うわけではないので、その都度追加することになりそう。

サンプルプロジェクトのビルドと実行

実行するとこんな感じ。

以上。

参考資料

2018年8月14日火曜日

debian で Google Test 環境を整える

とりあえず動作確認。

以下のプログラム test_example.cpp を実行できるところまで。

test_example.cpp

#include "gtest/gtest.h"

namespace {

TEST(Practice, First) {
    EXPECT_EQ(1, 1);
}

}

環境

  • OS: Windows 10 Pro
  • Docker: 18.06.0-ce, build 0ffa825
  • Image: debian:stretch-slim

debian アップデート

apt-get update

必要パッケージのインストール

C/C++ ビルドのために build-essential を、 googletest のソース取得とビルドのために、 googletest, cmake をインストール。

apt-get install build-essential cmake googletest

googletest のビルド

debian の googletest パッケージは、ソースしか入っていないので、ビルドする必要がある。

cd ${PATH_TO_WORK}
mkdir googletest
cd googletest
cmake /usr/src/googletest/googletest
make

これで、 libgtest.a, libgtest_main.a が生成される。 共有ライブラリとしてビルドしたい場合には、 cmake -DBUILD_SHARED_LIBS=ON /usr/src/googletest/googletest とすると .so を生成してくれる。

動作確認

あとは、ビルド時に .a-lpthread を使うようにすれば OK.

# テストビルド
cd ${PATH_TO_WORK}
g++ ./test_example.cpp ./googletest/libgtest.a ./googletest/libgtest_main.a -lpthread -o ./test_example

# テスト実行
./test_example
Running main() from gtest_main.cc
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from Practice
[ RUN      ] Practice.First
[       OK ] Practice.First (0 ms)
[----------] 1 test from Practice (0 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran. (0 ms total)
[  PASSED  ] 1 test.

はい。

MSYS2 で Google Test 環境を整える

とりあえず動作確認。

以下のプログラム test_example.cpp を実行できるところまで。

test_example.cpp

#include "gtest/gtest.h"

namespace {

TEST(Practice, First) {
    EXPECT_EQ(1, 1);
}

}

環境

  • OS: Windows 10 Pro
  • MSYS2

MSYS2 インストール直後の状態から始めます。

MSYS2 アップデート

# 1 回目は mintty とか pacman のアップデート
# 「×」でウィンドウを消して MSYS 再起動。
pacman -Syu
pacman -Syu

必要パッケージのインストール

主に g++, make, gtest のためのパッケージをインストールする。

pacman -Ss mingw-w64-x86_64-toolchain mingw-w64-x86_64-gtest

動作確認

基本これだけなので、最初のアレをもうビルドできるはず。

# テストビルド
g++ ./test_example.cpp -lgtest -lgtest_main -o test_example.exe

# テスト実行
./test_example.exe
Running main() from gtest_main.cc
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from Practice
[ RUN      ] Practice.First
[       OK ] Practice.First (0 ms)
[----------] 1 test from Practice (0 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran. (0 ms total)
[  PASSED  ] 1 test.

はい。

2018年7月22日日曜日

GitLab + GitLab Runner にクライアント認証を導入する

前回 の続き。 クライアント認証できるようにしていく。

環境

PATH_TO_WORKING_DIR も前回と同じ。

クライアント証明書作成

前回準備した openssl 環境でクライアント証明書を作る。

openssl 環境を実行

$WORKING_DIR="PATH_TO_WORKING_DIR"
cd $WORKING_DIR\work
docker-compose.exe run --rm openssl /bin/bash

openssl 環境での作業

CLIENT_COMMON="client.mikoto2000.example.com"
CLIENT_KEY_FILE="/client/${CLIENT_COMMON}.key"
CLIENT_CSR_FILE="/client/${CLIENT_COMMON}.csr"
CLIENT_CRT_FILE="/client/${CLIENT_COMMON}.crt"

CLIENT_COUNTRY="JP"
CLIENT_STATE="Tokyo"
CLIENT_LOCALITY="foo-ku"
CLIENT_ORGANIZATION="bar Inc."
CLIENT_ORGANIZATIONAL_UNIT="baz"
CLIENT_EMAIL="mikoto2000@gmail.com"

# クライアント秘密鍵作成
openssl genrsa -out ${CLIENT_KEY_FILE} 2048

# クライアント証明書要求作成
CLIENT_SUBJECT="/C=${CLIENT_COUNTRY}/ST=${CLIENT_STATE}/L=${CLIENT_LOCALITY}/O=${CLIENT_ORGANIZATION}/OU=${CLIENT_ORGANIZATIONAL_UNIT}/CN=${CLIENT_COMMON}"
openssl req -new -key ${CLIENT_KEY_FILE} -out ${CLIENT_CSR_FILE} -subj "${CLIENT_SUBJECT}"

# クライアント証明書要求確認
openssl req -noout -text -in ${CLIENT_CSR_FILE}

### クライアント証明書作成
cd /client

yes | openssl ca -out ${CLIENT_CRT_FILE} -infiles ${CLIENT_CSR_FILE}

### p12 形式に変換
COMMON="client.mikoto2000.example.com"
CACERT_FILE=/ca/cacert.pem
KEY_FILE=/client/${COMMON}.key
CRT_FILE=/client/${COMMON}.crt
P12_FILE=/client/${COMMON}.p12
openssl pkcs12 -export -out ${P12_FILE} -inkey ${KEY_FILE} -in ${CRT_FILE} -certfile ${CACERT_FILE}

gitlabの設定

設定ファイルの更新

docker-compose.yml を更新する。

version: '3'
services:
    gitlab:
        image: gitlab/gitlab-ce:11.0.1-ce.0
        restart: always
        hostname: gitlab.example.com
        container_name: gitlab.example.com
        volumes:
            - gitlab_etc:/etc/gitlab
            - gitlab_log:/var/log/gitlab
            - gitlab_opt:/var/opt/gitlab
        environment:
            GITLAB_OMNIBUS_CONFIG: |
                external_url 'https://gitlab.example.com/'
                gitlab_rails['gitlab_shell_ssh_port'] = 8022
                nginx['redirect_http_to_https'] = true
                nginx['redirect_http_to_https_port'] = 80
                nginx['ssl_verify_client'] = "on"
                nginx['ssl_client_certificate'] = '/etc/gitlab/trusted-certs/ca.crt'
                nginx['ssl_crl'] = '/etc/gitlab/CA.crl'
        ports:
            - "80:80"
            - "443:443"
            - "8022:22"
        networks:
            gitlab_net:
                ipv4_address: 172.16.238.2
    gitlab-runner:
        image: gitlab/gitlab-runner:v11.0.0
        restart: always
        hostname: gitlab-runner.example.com
        container_name: gitlab-runner.example.com
        volumes:
            - gitlab-runner_config:/etc/gitlab-runner
            - /var/run/docker.sock:/var/run/docker.sock
        depends_on:
            - gitlab
        networks:
            gitlab_net:
                ipv4_address: 172.16.238.3

networks:
    gitlab_net:
        ipam:
            config:
            - subnet: 172.16.238.0/24

volumes:
    gitlab_etc:
        external: true
    gitlab_log:
        external: true
    gitlab_opt:
        external: true
    gitlab-runner_config:
        external: true
  • nginx['ssl_verify_client'] = "on" : クライアント認証を on
  • nginx['ssl_client_certificate'] = '/etc/gitlab/trusted-certs/cacert.pem' : クライアント認証する際に信頼する ca 証明書の場所を指定
  • nginx['ssl_crl'] = '/etc/gitlab/CA.crl' : 失効リストの場所

証明書コピー

GitLab が信頼する CA 証明書を設置する。

適当なコンテナを起動して、コピー。

docker run -it --rm -v "PATH_TO_WORKING_DIR/work/client:/client" -v "gitlab_etc:/gitlab_etc" debian:stretch-slim /bin/bash
cp /client/ca.crt /gitlab_etc/trusted-certs/

gitlab-runner の設定

設定ファイルを変更

gitlab-runner のコンテナ内の /etc/gitlab-runner/config.toml を編集し、 クライアント認証用の設定を行う。

cd $PATH_TO_WORKING_DIR
docker-compose up -d
docker-compose exec gitlab-runner vi /etc/gitlab-runner/config.toml

/etc/gitlab-runner/config.toml を編集し、 tls-cert-file, tls-key-file を追加する。

/etc/gitlab-runner/config.toml

concurrent = 1
check_interval = 0

[[runners]]
  name = "gitlab-runner"
  url = "https://gitlab.example.com/"
  token = "a6219b6094d056e471105e5b026aec"
  executor = "docker"
  environment = ["GODEBUG=netdns=cgo"]
  tls-cert-file = "/etc/gitlab-runner/mycert/client.mikoto2000.example.com.crt"
  tls-key-file = "/etc/gitlab-runner/mycert/client.mikoto2000.example.com.key"
  [runners.docker]
    tls_verify = false
    image = "debian:stretch-slim"
    privileged = false
    disable_cache = false
    volumes = ["/cache"]
    extra_hosts = ["gitlab.example.com:172.16.238.1"]
    shm_size = 0
  [runners.cache]

[[runners]]
  name = "gitlab-runner"
  url = "https://gitlab.example.com/"
  token = "2c55ab3d9289874bfb7e265d37678b"
  executor = "docker"
  environment = ["GODEBUG=netdns=cgo"]
  tls-cert-file = "/etc/gitlab-runner/mycert/client.mikoto2000.example.com.crt"
  tls-key-file = "/etc/gitlab-runner/mycert/client.mikoto2000.example.com.key"
  [runners.docker]
    tls_verify = false
    image = "debian:stretch-slim"
    privileged = false
    disable_cache = false
    volumes = ["/cache"]
    extra_hosts = ["gitlab.example.com:172.16.238.1"]
    shm_size = 0
  [runners.cache]
  • tls-cert-file = "/etc/gitlab-runner/mycert/client.mikoto2000.example.com.crt" : クライアント認証に使うクライアント証明書の配置場所を指定
  • tls-key-file = "/etc/gitlab-runner/mycert/client.mikoto2000.example.com.key" : クライアント認証に使うクライアントの秘密鍵配置場所を指定

証明書・秘密鍵をコンテナにコピー

docker-compose exec gitlab-runner mkdir /etc/gitlab-runner/mycert
docker cp c:/Users/mikoto/project/gitlab-runner5/work/client/client.mikoto2000.example.com.crt 7875f5d4c9e2:/etc/gitlab-runner/mycert/
docker cp c:/Users/mikoto/project/gitlab-runner5/work/client/client.mikoto2000.example.com.key 7875f5d4c9e2:/etc/gitlab-runner/mycert/

動作確認

前回作った job を retry してみる。ok.

参考資料