• 何が起こったのか？
• 何をどうするのか？

何が起こったのか？

PlayStation4を持っているのだが、使っているうちにかなりファンの音がうるさくなってきた。
最近、任天堂Switchの修理をしまくっていたため、調子に乗って、分解清掃でもするか、とばらして掃除したところ、なんと、電源の信号部分のコネクタを壊してしまった。

基盤からコネクタを引っこ抜いてしまい、そのパターンも完全にはがれてしまった。。。

がしかし、なんと、先駆者がいらっしゃり、パターンをはがしても裏の基盤から直接信号を伝えることが出来るとのこと。

この時点で、めんどくさくなって放置していたが、昨日やっと手を付けたので記録を残したい。

何をどうするのか？

先駆者がまとめてくれていた動画は以下の通り。

https://youtube.com/watch?v=fRuwFATJ3Bc&si=UdmizDm7xKN9Va46

この動画を見ると、ピンの順序と意味は以下の通り。

で、このパターンと対応する露出が裏面に存在するとのこと。

これを適当に買ってきた導線につなぎ、ちぎれとんだ端子にはんだでつけなおす。

剥がれたパターン部分や、導線などは適当にビニールテープで押さえつけてつないだところ、無事復旧した。

また、改めてもう少し時間がある時にまとめようと思う。

Qiitaのアドベントカレンダーをいつも見ていて、いつか参加してみたいと思ってました。 はじめてのアドベントカレンダーという企画があることを知ったので、今回始めて参加してみようと思います。

何がしたかったのか？

子供のために、復習用の計算プリントをランダム生成するアプリケーションを作ってみた。
これはspring bootで作成した画面を持つWebサービスですが、なんとか無料で子供のタブレットから使えないかと、良い感じに転がす場所を探した結果 fly.io というサービスを見つけた。
デプロイまでに少しハマったので、この手順を記述した。

fly.ioとは

fly.io

herokuとかと同様にPaaS環境を提供してくれるサービスの一つで、herokuの無料利用分がなくなってしまったため、移行先として上がるサービスの一つ（らしい）。

このfly.ioは、herokuと同様にコンテナを起動することでアプリケーションを動作させるため、どんな言語のアプリケーションでも、最終的にはコンテナの中で動作する仕組みとなる。

公式ドキュメントでも触れられている通り、 Dockerfile によるデプロイが一番プレーンはデプロイ方法となり、標準で対応している言語はソースの自動判定により起動イメージを選択される。

実は、fly.ioではこの自動判定に含まれないJava（Spring Boot）でのイメージデプロイをpaketo buildpacksを利用してワンタッチで行えるため、この手順を試してみる。

まずは、ソースを用意する

プログラムは、 maine-coonというものを用意した。

これをクローンして試してみると良い。

ローカルで起動して、適切に動作するところまで実装をした。

> ./mvnw spring-boot:run
-> http://localhost:8080/

出来上がったらflyコマンドをインストール

flyctlのインストール

fly.ioはローカルからコマンドでコントロールすることができる。

このコマンドは2種類存在しており、 fly と flyctl が存在する。

どう使い分けるのか、正直良くわからない（ぇ

> curl -L https://fly.io/install.sh | sh
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1735    0  1735    0     0   4131      0 --:--:-- --:--:-- --:--:--  4140
######################################################################## 100.0%
set update channel to shell
flyctl was installed successfully to /home/vscode/.fly/bin/flyctl
Manually add the directory to your $HOME/.bash_profile (or similar)
  export FLYCTL_INSTALL="/home/vscode/.fly"
  export PATH="$FLYCTL_INSTALL/bin:$PATH"
Run '/home/vscode/.fly/bin/flyctl --help' to get started

fly.ioにログイン

事前にfly.ioでサインアップをしておく必要がある。

[!NOTE]
更に、これを試したとき（2023/12/03時点）では、無料利用においてもクレジットカード登録が必要な様子。

この上で、flyコマンドからログインを行う。

> fly auth login
failed opening browser. Copy the url (https://fly.io/app/auth/cli/XXXXXXXXXXXXXXXXXXX) into a browser and continue
Opening https://fly.io/app/auth/cli/XXXXXXXXXXXXXXXXXXX ...

Waiting for session...⣾

上記状況になった後、表示されたURLからブラウザでログインを行うと、コマンドのログインも完了する。

> fly auth login
failed opening browser. Copy the url (https://fly.io/app/auth/cli/XXXXXXXXXXXXXXXXXXX) into a browser and continue
Opening https://fly.io/app/auth/cli/XXXXXXXXXXXXXXXXXXX ...

Waiting for session... Done
successfully logged in as {{login user}}

アプリケーションの構築

まずは、fly.ioの自分の領域にアプリケーションのデプロイを行う場所を作成する。

> flyctl launch

以降、対話形式で諸々聞かれるため、必要に応じて設定する。

このやり取りが成功すると、カレントディレクトリに fly.toml が作成される。

[!NOTE]
この fly.toml が、デプロイを行うためのマニフェストファイルとなる。
ここに指示を記載することで、デプロイ後のセットアップをコントロールすることができる。

fly.tomlの編集

そのままではJavaはデプロイできないため、fly.tomlを編集する。

app = "maine-coon"
primary_region = "nrt"

[build]
  builder = "paketobuildpacks/builder-jammy-base:0.4.252"
  [build.args]
    BPE_APPEND_JAVA_TOOL_OPTIONS = "-XX:ReservedCodeCacheSize=30M -Xss256k"
    BPE_BPL_JVM_THREAD_COUNT = "10"
    BPE_DELIM_JAVA_TOOL_OPTIONS = " "
    BPE_SERVER_TOMCAT_THREADS_MAX = "2"
    BP_JVM_VERSION = "21"

今回は、paketo buildpacksを用いて、javaのビルドとイメージ化を行い、ここで作成したイメージを起動することで fly.io 上でアプリケーションを動作させる。

ただし、 fly.io の無料分で利用できるコンテナのリソースは少なく、 256mb のメモリで動作させる必要があるため、調整を入れている。

デプロイ

準備ができたら、実際にデプロイを行う。

> fly deploy

これで、カレントに存在する fly.toml に従ってログインしているアカウントにデプロイが行われる。

:
:
-------
Updating existing machines in 'maine-coon' with rolling strategy

-------
 ✔ [1/2] Machine 32874dddae6348 [app] update succeeded
 ✔ [2/2] Machine 9185991c207383 [app] update succeeded
-------

正常に起動が行われた場合、デフォルトで2コンテナが起動し、自動で割り当てられたURLでルーティングが行われる。

この先

これで、とりあえず動作することはできるようになったが、ソースの編集をしたあとにデプロイするまでのコマンドを打つのが面倒なため、CIを用意してデプロイを行った。

こちらについても別途記載をしたい。

• まとめ
• なんでこんなこと
• ということで、サンプル
• こまけぇことはいいから、どうなったん？
• ちなみに
• 参考資料

まとめ

• log4j2ならば、柔軟なローテション設定ができる
  • 起動時にすでにある場合のローテーション
  • ログ出力サイズによるログローテーション（今回はこれ）
  • 時間によるログローテーション
  • などなど
• log4j2ならば、ロールオーバーも簡単設定
  • 保持期限によるロールオーバー(今回はこれ)

なんでこんなこと

オンプレミスでのアプリケーションではログはローカルのディスクに書き込むことになる。（多分それ以外の方法もいっぱいあるんだろうけど、おそらく一番ベターでしょ）
この場合、バッチやら、logrotateでいい感じにローテートしたり、自動削除などを行うのが割と古くからされてる方法ではあると思うが、最新のログライブラリではその辺カバーすることが出来ると思いお試しをしてみた。

ということで、サンプル

サンプルアプリケーションとしては、spring bootの現時点（2023/06/25）での最新である、 3.1.1 を利用して、標準であるlogbackからlog4j2に変更した状態とした。

処理内容は、一定間隔でログを出し続けるコマンドラインアプリケーション。（つまり、何にもしないし、Webでさえない）

ソースはここ

こまけぇことはいいから、どうなったん？

今回目指したのは、ログを容量によってローテーションして、一定期間でロールオーバーする状況。

つまり、ログを別の機構で バックアップ or ログ基盤への転送 をする想定で、一定容量のみローカルには保持するような状態とした。
（バックアップさえできれば無運用）

手元で試すため、時間や容量は小さい状態で試している。

ちゃんと、一定のログ容量でローテーション＆ロールオーバーがなされていることを確認した。

以下log4j2のconfig。

<?xml version="1.0" encoding="UTF-8"?>
<Configuration strict="true"
           xmlns="http://logging.apache.org/log4j/2.0/config"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="http://logging.apache.org/log4j/2.0/config 
           https://raw.githubusercontent.com/apache/logging-log4j2/main/log4j-core/src/main/resources/Log4j-config.xsd">
    <Properties>
        <Property name="baseDir">logs</Property>
    </Properties>
    <Appenders>
        <Console name="Console" target="SYSTEM_OUT">
            <PatternLayout
                    pattern="%d{yyyy-MM-dd'T'HH:mm:ss.SSSZ} %highlight{%-5level}[%style{$${spring:spring.application.name},%X{traceId},%X{spanId},%X{sampled}}{blue}][%style{%t}{bright,blue}] %style{%C}{bright,yellow}: %m%n"/>
        </Console>
        <RollingFile name="ApplicationLog" fileName="${baseDir}/app.log"
                filePattern="${baseDir}/$${date:yyyy-MM}/app-%d{yyyyMMdd-hhmmss}.log.gz">
            <PatternLayout
                    pattern="%d{yyyy-MM-dd'T'HH:mm:ss.SSSZ} %-5level[$${spring:spring.application.name},%X{traceId},%X{spanId},%X{sampled}][%t] %C: %m%n"/>
            <Policies><!-- Policiesは必須。 ローテーションポリシー -->
                <OnStartupTriggeringPolicy /> <!-- 起動時にすでにログがあったら退避する -->
                <SizeBasedTriggeringPolicy size="1 KB" /> <!-- 指定容量に達した場合にローテーションする -->
            </Policies>
            <!-- <DefaultRolloverStrategy max="20"/> シンプルに最大保持数で指定することも可能。-->
            <DefaultRolloverStrategy><!-- 削除条件 -->
                <Delete basePath="${baseDir}" maxDepth="2"> <!-- maxDepthはbasePath配下のフォルダをどこまでたどるかの深度 -->
                    <IfFileName glob="*/app-*.log.gz" /> <!-- 削除対象のファイル名フォーマット定義。正規表現でも指定可能 -->
                    <IFLastModified age="P1M" /> <!-- この時間を過ぎたら削除する。形式はISO 8601 -->
                </Delete>
            </DefaultRolloverStrategy>
        </RollingFile>
    </Appenders>
    <Loggers>
        <Root level="info">
            <AppenderRef ref="Console"/>
            <AppenderRef ref="ApplicationLog" />
        </Root>
    </Loggers>
</Configuration>

ちなみに

ログロールオーバーの方の時間設定に関しては、 ISO 8601 を利用して設定するらしい。

ちょっと特殊なので気を付けたし。（頭にPがついているのはそういうものらしい。あとは、まぁ、ね）

参考資料

• log4j2でログローテートがしたかっただけなんだ - Qiita
• RollingFileAppender - Log4j – Log4j 2 Appenders
• Log Archive Retention Policy: Delete on Rollover - Log4j – Log4j 2 Appenders
• Spring Boot でロギングライブラリをLog4j2にする - Qiita
• ISO 8601 Durations - Wikipedia

spring boot3になってからtraceの構成が変わった。

sleuth から micrometer observationを使う用に代わり、opentelemetryが入ってきて関係性が変わったのでそれを把握したい。

micrometer observationの解説は優秀なブログがすでにあるのでそちらに任せることにする。

https://programacho.com/blog/a10b96ec9d79/

ここでは、このmicrometerの裏側を把握することを目的とする。

全体感から見た各種ライブラリの役割

▲ なにかのdiagramのルールにのっとって書いているわけではなく、雰囲気で矢印と図形の形を変えている。
意味はあるが公のルールではないのでご注意。

tracer layerの詳細

この領域はトレーサー層と呼ぶらしい。
ここは、exporter（braveではreporter）を使って実際のトレース情報を伝送する部分の実装であったり、アプリケーション間のトレース情報をつなぐための処理を行う実装が存在する。

braveはもともとのspring cloudに存在する実装であり、zipkinのb3ヘッダのみに対応している。

opentelemetryでは、opentelemetryが定義する伝送プロトコル（なんだっけ？）とb3のどちらにも対応しており、ここをpropagatorと呼んでおり差し替え可能となっている。

• w3c → W3CTraceContextPropagator
• b3 → B3Propagator

opentelemetryを使った場合のexporter layer詳細

Opentelemetryに対応したトレース参照用のツールはいくつか存在する。

これ以外にも、上記zipkinの例から以下のような構造になっていることが伺える。

参考資料のmakingさんの資料にある通り、spring boot 3.0.Xまでは、exporterのauto configに対応している（つまり何もBean登録しなくても設定だけで使えるやつ）のはzipkinとwavefrontのみとなっている。

しかし、opentelemetry自体はいろいろなexporterに対応しており、自力でBean登録をすることで異なるサービスにtraceを伝送することが可能になっている。

braveを使った場合のexporter layer(reporter)詳細

tracerをopentelemetryではなく従来のbraveを選択することも可能となっている。
この場合でも伝送先を切り替えることが可能となっている。

Opentelemetryに対応しているElastic APMに入れてみる

本リポジトリでは、前章でまとめた依存のうち以下のような組み合わせでアプリケーションを作成している。

• tracer layer -> opentelemetry
• exporter layer -> opentelemetry

tracerの記録先は Elastic APMを利用している。

詳しくは ../../pom.xml を参照いただきたいが、traceにかかわる依存は以下の通り。

		<dependency>
			<groupId>io.micrometer</groupId>
			<artifactId>micrometer-tracing-bridge-otel</artifactId>
		</dependency>

		<dependency>
			<groupId>io.opentelemetry</groupId>
			<artifactId>opentelemetry-exporter-otlp</artifactId>
		</dependency>

spring bootに関しては、3.0.x系であるため、そのままではopentelemetry exporterのauto configに対応していない。

このため、自分でBean登録を行った。

    @Bean
    SpanExporter otlpHttpSpanExporter() {
        return OtlpHttpSpanExporter.builder()
                .setEndpoint("http://localhost:8200/v1/traces") // <- elastic apm のエンドポイント
                .build();
    }

参考資料

Traceについての公式ドキュメントの記述

https://docs.spring.io/spring-boot/docs/3.0.5/reference/htmlsingle/#actuator.micrometer-tracing

makingさんの最強資料

https://bit.ly/springboot2023

業務で利用するLinux Serverを新規で作成することになった。
既存のLinux Serverの横に追加することになっているため、追加するサーバのOSも併せようと考えたが、現在CentOSはバージョンアップ方針が変わっており、そのまま採用すべきではないのではないか、となった。

適切なOSを選定するとともに、CentOSの事情を把握しておきたいため、調査する。

CentOSの事情

元々の流れ

CentOSは Red Hat Enterprise Linux（以降RHEL）というディストリビューションの系列に属しており、RHELと機能的に互換性があることを目指したフリーのLinuxディストリビューションである。

RHELに含まれているソフトウェアの中にはOSSで無償公開しているため、これをもとに、商標や商用パッケージをのぞいたものをリビルドして提供している。そのため、「RHELクローン」と呼ばれることもある。(CentOS自体は公式には否定している)

最初期ではRHELを提供するレッドハットは関わっていなかったが、2014年からCentOSを正式に支援していくことを表明していた。

しかし、2020/12/8にCentOSからCentOS Streamに開発の主軸を移動し、CentOS Linux 8のサポートを2021年に停止している。RHEL 9に対応するCentOS Linux 9は提供さず、今後はCentOS Stream 9の提供とする。

Red Hat Enterprise Linux派生ディストリビューション

Red Hat Enterprise Linux派生ディストリビューション

RHELには様々なディストリビューションが存在する。大きくは、まず同社がメンテナを行っているFedora Linuxがある。これは、もともとはRHELの無償版であった。

しかし、Fedoraはサポート期間が比較的短く、実験的なリリース方針であったため、長期サポートを望むユーザとしては利用に適していなかった。

RHELはコンパイル済みのものを無償提供していないが、完全なソースコードを公開しているため、これを入手し再コンパイルすることで派生ディストリビューションの作成が行われている。

CentOSのサポート情報

CentOS

CentOS Stream

CentOS StreamはRHELとFedora Linuxの中間を目指したディストリビューション。

Fedoraは実験的なリリースを取り込み、RHELの将来のメジャーリリースのベースとなるアップストリームプロジェクトであったが、CentOS StreamはRHELの次のバージョンとなる変更を取り入れたRHELのプレビューとなる。

このような性質の変更があったため、重要なビジネスアプリケーションやプロダクション環境での使用は推奨されておらずRHELが進められる。

元々のCentOSの性質としては、他のRHELと同様にコードのリビルドから生成されたものであり、個別メンテナンスであったため、今回の変更で性質ががらりと変わる。

やはり商用利用を考えた場合、（本質的にはRHELを使え、なのだが）あまり利用は推奨されるべきものではなくなるという見解があちらこちらで見られた。

派生ディストリビューションについて

CentOSの事情を鑑み（結局ただ乗りになるのだが。。。）、同じ要件をかなえるためのディストリビューションが多数生まれている。

もし、無償版を利用するならばこの中から選定すべきだと考えられる。

Rocky Linux

Rocky Linux
Rocky Linux

RHELのソースコードを利用した、完全バイナリ互換性のあるリリースであることを意図しており、コミュニティがサポートする、商業品質の企業向けOSを提供することを目的としている。

背景として、CentOS Streamが発表された後、CentOSの初代創設者である Gregory Kurtzer氏が、元のCentOSの目的を達成するために立ち上げたプロジェクトである。

パートナー企業としては、ArmやVMWare、AWS、Google Cloudなども参加しており、従来のCentOSと同等のもののとなっている様子。

AlmaLinux

AlmaLinux
AlmaLinux OS - Forever-Free Enterprise-Grade Operating System

Rocky Linuxと同様の動機と目的をもって開発されているディストリビューション。

しかし、こちらは、CloudLinux OSというRHELベースの商用Linuxディストリビューションを開発しているCloudLinuxが作成している。

また、このCloudLinuxは、別途AlmaLinux Open Source Foundationという非営利組織を設立し、AlmaLinuxの管理はこの組織に引き継いだ。

Oracle Linux

Oracle Linux
Oracle Linux

Oracle社によりRHELの商標やロゴの差し替えを行い、再構築したディストリビューション。

Oracleへのユーザ登録を行うことで無料で利用することが可能。

厳密には、RHELだけではなく、別のLinuxカーネルを含めたディストリビューションであり、Oracleにより一部強化されているため、完全互換ではないとレッドハットが公表している。

しかし、AWSでも選択できるほか、Oracleが提供するOracle Cloudでは標準OSとして利用されるなど実績を持つ。

• なんぞ？
• 何がいいねん
• 使い方
  • ベースイメージ
  • featureについて
  • 拡張機能も宣言しよう
  • 事前処理を記述する
• オリジナルfeatureの作成
  • テンプレートからの新規リポジトリ
  • 開発環境構築
  • テストを試す
  • GitHub Action
  • 実際に組み込んでみる

なんぞ？

Microsoft製のOSSエディタであるvscodeに追加された便利機能について。

端的に言うと、コンテナ環境に開発環境を構築し、直接vscodeで開くことで開発専用のsandbox内で開発ができるという代物。

決まり事である、 .devcontainer というフォルダや json の定義に開発環境の状態を記述することで、どの端末でも同一の環境をコンテナ上に作成し開発を行うことができる。

各開発者の環境固有の設定などを排除することで環境差異を極力減らす事を目的としている。

こっからポエム

各個人の開発環境に対してこだわりを持っていくことはどの開発者でもわかると思う。しかし、開発環境の多機能化が進んでしまったことで開発用IDEの設定というものはかなり煩雑になってきている。いろいろな端末で自身のIDEの設定を同期させる拡張機能などは存在するもの、用途によって必要となる拡張機能は様々となる。必要な時に必要な拡張機能やツールを使うことでシンプルに環境を保つことは困難になる一方で、これを解決するため、各リポジトリ事に開発環境を持つ思想が生まれるのは必然ではないか。もはや、自身の環境は常に空っぽで、リポジトリ事に開発環境・ツールを整備すればすべてがシンプルになるのではないか？！と思った次第で、とても感銘を受けているからこれを書き始めた（オタク特有の早口）。

何がいいねん

上で書いてしまっているが、開発者が持つ個人端末固有の設定に依存せず、常に同一の環境で開発を行事ができるため、ハマりずらくなる。

また、クラウド上に開発環境を作成し、ブラウザで開発を行うスタイルの開発環境では、クラウドに作成する開発環境についても同様の設定で動作させることができる（と思う。試してない）。

使い方

以下のようにワークスペース中に devcontainer.json を用意する。

/root/
|-- .devcontainer/
|   `-- devcontainer.json
|-- src
|   |-- main
|   :
:

ルートまたは、 .devcontainer フォルダ配下に用意することで、vscodeを開いた際に通知にdevcontaerで開きなおすかどうかが聞かれる。

または、このルートフォルダで、 devcontainer open . とコマンドを打つことで直接vscodeで開くことができる。

この devcontainer コマンドは、vscode上のコマンドでインストールすることが可能。

これらは、拡張機能のDev Containersを入れることで有効になる。

ベースイメージ

拡張機能が入っていれば、vscode上で devcontainer.json を生成することも可能。

そちらから作成すれば、ベースイメージは選択式で選ぶこともできる。

このベースイメージは、多種多様のものがあり、シンプルな Ubuntu や、 Alpine から、RubyやJavaなど開発対象の言語に特化したものが存在する。

また、docker-composeファイルにも対応しており、ベースイメージ＋composeで周辺ミドルウェアの立ち上げまで行うことができる。

（もちろんcomposeで立ち上げるため同一ネットワークに所属させることも可能であるため、ホスト名でアクセスしやすくなる）

featureについて

ベースイメージを選択した後に聞かれるのがfeatureになる。

このfeatureは、ベースイメージの中にインストールするコマンドなどを管理するもの。

Gitコマンドやjq、SDKMANやAnacondaなど開発に利用するコマンド類を最初からセットアップされた状態で使える。

これらを選択すると生成される devcontainer.json では、どのベースイメージでfeatureを利用するかを定義することが可能となり、別のPCで同一の開発環境を構築することが可能となる。

{
	"name": "Docker in Docker",
	"image": "mcr.microsoft.com/devcontainers/base:buster",
	"features": {
		"ghcr.io/devcontainers/features/common-utils:1": {
			"installZsh": "false",
			"upgradePackages": "true",
			"uid": "1000",
			"gid": "1000",
			"installOhMyZsh": "true",
			"nonFreePackages": "true"
		},
		"ghcr.io/devcontainers/features/docker-from-docker:1": {
			"version": "latest",
			"enableNonRootDocker": "true",
			"moby": "true"
		},
		"ghcr.io/devcontainers/features/docker-in-docker:1": {},
		"ghcr.io/devcontainers/features/git:1": {},
		"ghcr.io/devcontainers/features/java:1": {},
		"ghcr.io/eitsupi/devcontainer-features/jq-likes:0": {},
		"ghcr.io/devcontainers/features/terraform:1": {},
		"ghcr.io/meaningful-ooo/devcontainer-features/homebrew:2": {},
		"ghcr.io/shibadog/devcontainer-feature/graphviz:latest": {}
	},
:
:
}

拡張機能も宣言しよう

devcontainerで開いたvscode上では拡張機能はホスト側から引き継がれたりはしない。
そのため、それぞれインストールの必要があるが、これを devcontainer.json に宣言することができる。
（つまり、最初からインストールされた状態で起動することもできる）

これは、 devcontainer.json を直接編集して追加することもできるが、 devcontainer で起動したvscode上から拡張機能をインストールするタイミングで追加することも可能となっている。

また、常に入れておきたい拡張機能は、 Dev Containers 拡張機能の設定で定義することができる。

事前処理を記述する

だいたいfeatureで必要な事前処理は行うことができるようになっているが、あまり一般的ではない、プロジェクト固有の前処理などがあった場合は、 postCreateCommand で事前処理を行うことが可能である。

  :
  :
	// Use 'postCreateCommand' to run commands after the container is created.
	"postCreateCommand": "docker --version",
  :
  :

同じく、 devcontainer.json の中に、 postCreateCommand を用意しておくことで、任意のコマンドを実行することが可能となる。
ここで、事前処理などを行うことが可能となる。

もちろん、コマンドのみならずシェルスクリプトなど実行ができるので .devcontaier フォルダに格納して管理することも可能である。

オリジナルfeatureの作成

実はここで出てくる feature というものは簡単に自作することができる。

これが実は真価を発揮する場面であり、今回最大に感動している点。

こちらにテンプレートリポジトリが用意されており、これをもとに作成したリポジトリでオリジナルfeatureを作ることができる。

また、nodeで開発された devcontaer-cli を使うことで、簡単にテストを記述することもでき、このテンプレートリポジトリには devcontainer-cli を用いたテストや Github Package を用いたパッケージ化の Github Action が含まれている。

これを、 devcontainer.json の feature に追加することですぐに利用することができる。

以下で簡単に自作した feature を追加してみる。

テンプレートからの新規リポジトリ

featureを作るにあたって、公式からテンプレートリポジトリが提供されている。

GitHub - devcontainers/feature-starter: A bootstrap repo for self-authoring Dev Container Features

これには、Github Actionsによるビルドとリリースのjobが定義されているため、定義追加後にGithub Actionsをそのまま実行することでfeature自体を利用することが可能となっている。

実際に作成したリポジトリは以下の通り。

GitHub - shibadog/devcontainer-feature

開発環境構築

テンプレートリポジトリから作成した場合、すでに devcontainer が用意されているため、vscodeで開くと devcontainer で開くことをを促される。

これにより、devcontainer-cli が利用でき、dockerが利用できるコンテナで開発が行える。

テストを試す

基本的に devcontaer-cli を利用することでテストなどが簡単に行える。

GitHub Action

実際に組み込んでみる

Javaとの対比が一番わかりやすいのでいったん対比を書く

いろいろ使い方

シンタックス回り

変数

通常は何も書かずに代入で切るっぽい

variable = 'だいにゅうできるよ';
puts variable;

ローカル変数を作りたければ以下。

@variable = 'ローカル変数！';
puts @variable;

クラスの中でクラス変数を定義したい場合はアットが二つ

class Clazz
    @@field = nil;
 
 
    def method_dayo
        @@field = 'フィールドだよ';
        puts @@field;
    end
end

スクリプトとして使う場合はグローバル変数なんてのもあったね。

$variable = 'ぐろーばるなかんじ';
puts $variable;

ビルド

bundlerだったりrakeだったりminitestだったりとツールがパラパラと存在していて、それぞれ別で実行するのは嫌になる。。。

node周りと同じように、ルートになるツールは何を使うべきか調べてみたけど、どうやらbundlerを使うスタイルが多そう。

（でも、rakeがビルドツールなのだからrakeから全部やりたくなるんだけどできないのか？）

Spring Vault

VaultはHashiCorpのプロダクトで、クレデンシャル情報を保持するミドル。

Vaultはコマンドラインでクレデンシャル情報の設定・取得が可能だが、spring boot vaultを使って、Configurationとしてアプリケーションの設定を連携することができる。

spring cloud configと同様に、 bootstrap.properties でVaultへの接続情報を設定することで、読み込みを行うようだ。

application.yml を作成してそこからの設定値読み込みと同時に使用しても問題なく使えた。 (まぁ当たり前か。)

RabbitだのAWSだのElasticsearchだののクレデンシャル情報に対応していると記載されているところから、 bootstrap.properties で操作することで、対応するミドルウェアのクレデンシャル情報を通常の application.yml に設定するのと同様の状態で設定することができるようだ。

どのへんでうれしさを感じるのだろうか？
環境変数で刺すようにするサービスブローカーとどう違うのか。。。？

よりアプリケーションに近い位置でクレデンシャルを設定できるので、良いような悪いような。

コンテナ運用の場合はコンテナ管理ミドルによって環境変数にさしてほしい気もする。

コンテナ管理ミドルを使わずに、手運用デプロイしているときにうれしいとか？
そんな状況で（クレデンシャル管理が）いる？
（そんなならば application.yml にべた書きしてもよいじゃないか）

K8Sな言葉がちょいちょい出てくるので何か想定する運用があるっぽい気もするけど、調べるの飽きてきたのでそろそろ終わる。

イライラ、もやもやしたときにいつも作るユニット折り紙を並べて行こうという試み。

今回、いつも使っているユニット折り紙の本以外から情報を得て作ったので、作り方を残しておくというのもある。

完成図

作り方

思ったよりも、Draw.ioで折り紙書くの辛かった（何

折り紙の図面は表裏がわかるように範囲色付けとか、変形させた際に微調整をするために、線同士の結合をしたまま移動させるとかの機能があったほうがいい。。。
つまり、ちゃんとしたお絵かきソフトで作ったほうが断然効率がいいということが分かったorz

でもちょっと面白かった

広義の意味では、動作の高速化を図るため、低速・安価な記憶領域から高速・高価な記憶領域へ一時的に情報を保持することを指す（と思う）。

ブラウザキャッシュは主に、ブラウザの描画に使うリソース（HTML、JS、CSS、画像など）を一定期間ローカルに保持することにより、再度ネットワークアクセスを行った際に高速に表示させる機構を指す（はず）

もちろん、昨今使われる動的ページ（Webシステムによるレスポンス）で生成されるHTMLなどのボディ部分に関しては、キャッシュする意味がないため、使用されない。
しかし、ロゴなどの画像を動的に表示することは特定の状況下以外ではまれであるため、静的コンテンツなどと呼び、キャッシュ対象にする。

また、JavaScriptによる動的描画を中心とした動的ページ（シングルページアプリケーション）は、ユーザ側（⇔サーバ側）であるブラウザによる描画になるため、ソースであるJavaScriptは静的コンテンツ扱いが可能になる。

静的コンテンツを高速化する仕組みとして、一種のキャッシュシステムであるCDNというものもの存在する。
ブラウザキャッシュとは異なるが、いわゆる広義のキャッシュという意味では同じ目的の仕組みになる。

これはこれで話が長そうなので、また別途。 参考:さくらのナレッジ - CDNってそもそも何？なんかサーバの負荷が下がるって聞いたんだけど！〜Web制作/運営の幅が広がるCDNを知ろう第1回〜

Browser Cacheのコントロール

HTTPのレスポンスヘッダにより、サーバ側からリソースのキャッシュをコントロールすることができる。 https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Cache-Control

cache-control というヘッダを用いる。

キャッシュを抑止したい場合は、 cache-control: no-store を用いる。

有効期限の設定

様々な指定の仕方で有効期限を設定することができる。 初めてキャッシュを行う時刻からの有効期限秒数を指定する。

特定の日付で有効期限が切れる形式の場合は、このヘッダではなく専用の Expires ヘッダを用いる。

https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Expires

デフォルトの設定

springMVCで作られたwebシステムはもちろん動的サイトであるため、cacheしたくないはずだが、 デフォルトではどのような動きをするか？

ChromeはDevToolを開いて通信をすると、 cache-control: max-age=0 でリクエストを飛ばすっポイ？
これが原因かわからないけれども常にキャッシュされないし、レスポンスヘッダには cache-control は設定されない。

自分で制御

ResponseEntityオブジェクトでキャッシュコントロールを明示することができる。

@GetMapping("/users/{name}")
public ResponseEntity<UserDto> getUser(@PathVariable String name) {
    return ResponseEntity.ok()
      .cacheControl(CacheControl.maxAge(60, TimeUnit.SECONDS))
      .body(new UserDto(name));
}

動的レスポンスをキャッシュさせたい場合はまぁあれだけど、静的コンテンツをthymeleafでドウコウしたときのキャッシュってどうやって制御するんだろう？

正式名称は HTTP Cookie .

端的に言うと、クライアントに情報を保持することができる仕組み。

JavaScriptやサーバからのHTTPレスポンスにより保持させることができる。
また、JavaScriptならロジックで読み取りが可能で、HTTPサーバ通信の場合は、許可されているCookieを通信の際に自動付与して送信する。

ServerからCookieを設定する場合は、レスポンスヘッダに Set-Cookei を付与することで設定できる。
JavaScriptの場合 document.cookie でアクセスできる。

保持可能情報

SameSiteとは？

有効期限

Session Cookie

有効期限など指定しない場合は大体のブラウザがこの挙動となる。
ブラウザ（タブ？）が閉じられない間は保持し続ける。
ブラウザ側でよく出てくる「セッションの復元」をすると復元される。

持続的Cookie

有効期限を設定して設定した場合の挙動。
ブラウザ（タブ？）を閉じたとしても保持し続ける。
有効期限または指定した期間に到達した場合に無効になる。

参考資料

• MDN - HTTP Cookie
• MDN - Set-Cookie
• Qiita - Chrome 80が密かに呼び寄せる地獄 ～ SameSite属性のデフォルト変更を調べてみた(@ahera)

C#でWPFを使った開発を経験しているが、Javaでも同様の仕組みであるJavaFXが出たので、JavaFXが気になって仕方がない。

いまさらながら、調べてみようという話

現在SpringによるWebバックエンド開発が主な仕事なので、その辺の知識を生かしてうまいことJavaFXに適用できないかも模索してみる。

完全にJavaFXは初心者である

環境構築

JavaFXはJava11から本体から切り離された様子。 （この辺深堀している記事がありそうなので探そう。。。）

取り急ぎ、ググった結果ぱっと出てきたGluonが出しているOpenJavaFX11の環境構築を行った。

開発環境はもちろんWindowsなので、パッケージ管理にScoopを使う。

scoopの公式拡張bucketのjava bucketを追加してインストールする。

PS> scoop bucket add java
PS> scoop update
PS> scoop search javajfx
'java' bucket:
    gluon-openjfx-jmods-ea (15-5)
    gluon-openjfx-jmods-lts (11.0.2)
    gluon-openjfx-jmods (14.0.1)
    gluon-openjfx-sdk-ea (15-5)
    gluon-openjfx-sdk-lts (11.0.2)
    gluon-openjfx-sdk (14.0.1)
PS> scoop install gluon-openjfx-sdk-lts

もちろん、javaも必要なのでインストールしておく

PS> scoop install openjdk11

あと、画面を作成するためのXMLエディタとしてscene builderというものが存在する。

WPFの画面作成のアレと同じことができる。

これはscoopに存在しなかったので、適当に自分でscoop bucketを作ったので追加してインストール

PS> scoop bucket add my-bucket https://github.com/shibadog/my-bucket.git
PS> scoop update
PS> scoop search scene-builder
'my-bucket' bucket:
    gluon-scene-builder (11.0.0)
PS> scoop install gluon-scene-builder

これで実行環境と開発SDKのインストール完了。

エディタはvscodeを使う

PS> scoop search vscode
'extras' bucket:
    vscode-insiders-portable (nightly)
    vscode-insiders (nightly)
    vscode-portable (1.45.1)
    vscode (1.45.1)

'main' bucket:
    llvm (10.0.0) --> includes 'lldb-vscode.exe'
    winpython (3.8.2.0) --> includes 'winvscode.bat'
PS> scoop bucket add extras
PS> scoop update
PS> scoop install vscode

あ、ビルドツールはmavenを使うので、これもscoopで入れておく。

PS> scoop search maven
'main' bucket:
    maven (3.6.3)
PS> scoop install maven

vscodeには、諸々Java開発のための拡張機能など入れておいてね。

vscodeでの環境構築

取り急ぎ、mavenプロジェクトを作ってから開発しないといかんので、諸々ベースを作る。

PS> mvn archetype:generate
Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains): 1605:
Choose a number: 8:
Define value for property 'groupId': com.github.shibadog
Define value for property 'artifactId': javafx-test
Define value for property 'version' 1.0-SNAPSHOT: :
Define value for property 'package' com.github.shibadog: :
 Y: : y
PS> ls

Mode                LastWriteTime        Length Name
----                -------------         ------ ----
d-----       2020/05/23     22:32                javafx-test

あとラッパも作っておく

PS> cd javafx-test
PS> mvn -N io.takari:maven:0.7.6:wrapper

giboで適当にignore作っておく

PS> gibo dump VisualStudioCode Maven Java Eclipse >.gitignore

powershellだとUTF-16になっちゃうので（これなんとかならんのかいな）、vscodeで開いて文字コードをUTF-8に変えておく。

pomのjdkバージョンを11に変更

diff --git a/pom.xml b/pom.xml
index 4c0c6e2..e9aed17 100644
--- a/pom.xml
+++ b/pom.xml
@@ -14,8 +14,8 @@

   <properties>
     <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
-    <maven.compiler.source>1.7</maven.compiler.source>
-    <maven.compiler.target>1.7</maven.compiler.target>
+    <maven.compiler.source>11</maven.compiler.source>
+    <maven.compiler.target>11</maven.compiler.target>
   </properties>

   <dependencies>

肝心のjavaFxの依存を追加

diff --git a/pom.xml b/pom.xml
index e9aed17..b2a3002 100644
--- a/pom.xml
+++ b/pom.xml
@@ -19,6 +19,16 @@
   </properties>

   <dependencies>
+    <dependency>
+      <groupId>org.openjfx</groupId>
+      <artifactId>javafx-controls</artifactId>
+      <version>11.0.2</version>
+    </dependency>
+    <dependency>
+      <groupId>org.openjfx</groupId>
+      <artifactId>javafx-fxml</artifactId>
+      <version>11.0.2</version>
+    </dependency>
     <dependency>
       <groupId>junit</groupId>
       <artifactId>junit</artifactId>

これでもう作れるはず。 とりあえずMainクラスをJavaFXに改造

diff --git a/src/main/java/com/github/shibadog/App.java b/src/main/java/com/github/shibadog/App.java
index 351a4f4..afe5546 100644
--- a/src/main/java/com/github/shibadog/App.java
+++ b/src/main/java/com/github/shibadog/App.java
@@ -1,13 +1,20 @@
 package com.github.shibadog;

-/**
- * Hello world!
- *
- */
-public class App
-{
-    public static void main( String[] args )
-    {
-        System.out.println( "Hello World!" );
+import javafx.application.Application;
+import javafx.stage.Stage;
+
+public class App extends Application {
+
+    @Override
+    public void start(final Stage stage) {
+        try {
+            stage.show();
+        } catch (final Exception e) {
+            e.printStackTrace();
+        }
+    }
+
+    public static void main(final String... args) {
+        Application.launch(args);
     }
-}
+}

実行の時にミソ。vscodeのlaunch.jsonでjavaFx用のモジュールを指定して実行するように設定を入れる。

vscodeのデフォルト設定でlaunch.jsonを作成する。

{
    // IntelliSense を使用して利用可能な属性を学べます。
    // 既存の属性の説明をホバーして表示します。
    // 詳細情報は次を確認してください: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "type": "java",
            "name": "Debug (Launch) - Current File",
            "request": "launch",
            "mainClass": "${file}"
        },
        {
            "type": "java",
            "name": "Debug (Launch)-App<javafx-test>",
            "request": "launch",
            "mainClass": "com.github.shibadog.App",
            "projectName": "javafx-test"
        }
    ]
}

このあと、モジュール追加

diff --git a/.vscode/launch.json b/.vscode/launch.json
index c0f83a8..8e410e4 100644
--- a/.vscode/launch.json
+++ b/.vscode/launch.json
@@ -8,14 +8,16 @@
             "type": "java",
             "name": "Debug (Launch) - Current File",
             "request": "launch",
-            "mainClass": "${file}"
+            "mainClass": "${file}",
+            "vmArgs": "--module-path ${env:USERPROFILE}\\scoop\\apps\\gluon-openjfx-sdk-lts\\current\\lib --add-modules javafx.controls,javafx.fxml"
         },
         {
             "type": "java",
             "name": "Debug (Launch)-App<javafx-test>",
             "request": "launch",
             "mainClass": "com.github.shibadog.App",
-            "projectName": "javafx-test"
+            "projectName": "javafx-test",
+            "vmArgs": "--module-path ${env:USERPROFILE}\\scoop\\apps\\gluon-openjfx-sdk-lts\\current\\lib --add-modules javafx.controls,javafx.fxml"
         }
     ]
 }

これでやっとvscodeから起動ができる。

開発環境の構築完成！！

暗号化アルゴリズム

暗号化と複合

暗号化は誰でもアクセス可能なパブリックな場所でデータを転送する際に、第三者にデータを盗み見されたり、改ざんされないようにデータを守るために用いられる。

暗号化や複合は、暗号化アルゴリズムと鍵によって行われる。

2種類の暗号化方式

暗号化アルゴリズムには大きく分けて2種類のものがある。

• 共通鍵暗号
• 公開鍵暗号

共通鍵暗号

この方式は、直観的に理解しやすい。

いわゆる現実で用いる「鍵」と同様の方法で、一つの「鍵」を用いて鍵をかける（暗号化）ことができ、さらに同じ「鍵」で鍵を開ける（複合化）できる。

また、この「鍵」を「共通鍵」と呼ぶ。

欠点と相手は、暗号化する側と、複合化する側が異なる場合に同一の「共通鍵」をそれぞれが保有している必要がある。

これは、「共通鍵」を他人が知り得てしまった場合は、その他人が暗号文を解読できてしまうというリスクが発生する。

公開鍵方式

この方式は、少し現実で表現しにくい。

二つの鍵を用意し、それぞれ、「暗号化用」と「複合化用」とする。

「暗号化用」の鍵を「公開鍵」と呼び、「複合化用」の鍵を「秘密鍵」と呼ぶ。

使用するときは、複合化する側が2つの鍵を生成し、「公開鍵」を暗号化する側に渡す。

渡された暗号化する側が「公開鍵」で暗号化を行った後、複合化する側に暗号文を渡す。

複合化する側は「秘密鍵」を用いて暗号文を複合化できる。

この方式の特徴は、「公開鍵」で暗号化したものは「秘密鍵」でのみ複合化できるということで、かつ、「公開鍵」を用いて「秘密鍵」を推測することができないことである。

「公開鍵」を知り得ても暗号化はできても複合化ができないため、必ず「秘密鍵」を持っているものしか暗号文を解読することはできない。

欠点としては、共通鍵方式と比べると処理（暗号化・複合化）の速度が遅い。

ハイブリット方式

それぞれの方式には利点・欠点がありそれを補完するためにはブリット方式が存在する。

ハイブリット方式では、データの暗号化には「共通鍵方式」を用い、この「共通鍵」を受け渡す際に「公開鍵方式」で暗号化を行うというものである。

「共通鍵」の漏えいリスクを「公開鍵方式」で担保し、高速な「共通鍵方式」のアルゴリズムでデータを担保するという手法。

共通鍵方式の中での2種類の方式

共通鍵方式の中で、その手法を大きく2つに分けることができる。

それが以下の2つの種類の暗号化方式である。

• ブロック暗号
• ストリーム暗号

ブロック暗号

ブロック暗号は、暗号化対象の平文データを一定の長さのブロックに分割して暗号化を行う手法である。

通常、平文データは1byte単位の可変長であるが、1byteごとに1byteの暗号文としていた場合は256通りのパターンでしかないため、簡単に解読されてしまう。

これを防ぐために、8byte（64bit）や、32byte（256bit）といった、より大きな「ブロック」ごとにまとめて暗号化する方式で解読を難しくしている。

ストリーム暗号

ブロック暗号では、ブロック毎に暗号化をすることで1byte毎の暗号化よりも解読を難しくしているが、結局ブロック長が短ければパターン数が少なく解読の難易度も下がってしまう問題は変わらない。

ブロック長を十分な長さにしたとしても、過去あった暗号化方式であるDESでも起こったように、コンピュータの性能向上によって脆弱なアルゴリズムになってしまう。

そこで、任意長の鍵ストリーム列を生成させ、これと入力の平文を演算させる「ストリーム暗号」が考え出された。

これは、1bitや1byte単位でデータを暗号化でき、かつ、パターンを十分に増やせる。

また、対象の平文の長さを気にしなくて済むため、SSL（HTTPS）や無線LAN（WEP）など、ネットワークトラフィックを暗号化するために利用されている。

暗号化アルゴリズムの種類

暗号化アルゴリズム一覧

暗号利用モード (Block cipher modes of opration)

暗号化のアルゴリズムとは別に、暗号化を行う手順についての規格（？）。

また、このモードはブロック暗号と呼ばれる暗号方式の際に利用する。

代表的なECBモードといわれる方法では、鍵で平文を暗号化する際に単純に一回暗号化処理を行う。この状態では、同じ平文を同じパスワードで暗号化した場合、暗号化結果が同一になってしまうため、パターンを解析することで平文が求められてしまう。

これを防ぐためのやり方がそのほかのモードである。

ECB(Electronic Codebook)モード

最も単純な暗号利用モードである。 平文を決まったブロック(長さ)に分けたのち、そのブロックをそれぞれ独立して暗号化する。

EBCモードの欠点は、上記にも記載した通り、同じ鍵を用いた場合ある平文ブロックを暗号化した結果の暗号ブロックが常に同じになることである。

CBC(Cipher Block Chaining)モード

この方式はIBMによって考案された方式で、各ブロックの平文を前のブロックのXORをとってから暗号化させる。

この方法をとることによって、同一のパスワード・平文であったとしても、文脈が異なれば暗号化結果が変わる状態となる。

また、最初のブロックについては、前のブロックが存在しないため、代わりになるInitialization Vector(IV)という初期値を与える。

これは、最初のブロックに対して前のブロックの代わりになるため、ブロック長と同じ長さを指定する必要がある。

この方式の欠点は以下の2点があげられる。

• ブロックの暗号化に前のブロックの情報が必要であるため、暗号化は並列で行うことができない。
• 暗号ブロックの長さを固定化しなければならないため、対象の平文をブロック長の整数倍の長さにパディング（空白埋めなど）しなければならない。

Niels FergusonおよびBruce Schneierによって推奨される二つの暗号化の一つである。

PCBC(Propagating Cipher Block Chaining)モード

あまり主流ではないCBCモードの変法である。

CBCモードでは、前のブロックの暗号結果を次のブロックに対してXORをかけた後に鍵で暗号化をかけていたが、PCBCモードでは、前のブロックの暗号化結果とそのブロックの暗号化前の平文をXORした結果で次のブロックの平文をXORし、鍵で暗号化する。

特徴としては、隣接する2つの暗号文ブロックを入れ替えたとしてもそれ以降のブロックの複合に影響しないこと。

CFB(Cipher Feedback)モード

CBCモードと似ているが、どちらを主として考えるかという違いのようである。

手順としては、IV（または前の暗号化結果）を暗号化し、その結果に次のブロックをXORして暗号化結果とする。

これは、CBCモードと同様に、並列処理ができない作りである。

また、これもCBCモードと同様だが、平文1ビットの変更で暗号文全体が変わってしまう。

CBCモードと比べて利点となるのは、パディング処理を行わなくともよいという点である。

OFB(Output Feedback)モード

CFBモードの亜種みたいなもので、次のブロックの元となる暗号化ブロックを、前のブロックでXORをかける前の暗号化ブロックを用いる。

利点としては、暗号化前でも前方誤り補正を適用できることのようだが、正確な意味を理解できていない。。。[TODO]

また、細かい部分の説明を省くが、CBCモードを入力がすべて0で実施したときの暗号化ブロックが、OFBモードのブロックごとの入力値となるため、ハードウェア的な高速CBC機構を用いてOFBモードを実施する事が可能である。

CTR(Counter)モード

Counterと呼ばれる値とNonceと呼ばれる値を組み合わせ、暗号化処理をかけた結果を平文のブロックにXORすることで暗号化する。

Counterは単調増加であり値が重複することがなければどんな値でもよいが、1ずつ増加する値を用いることが一般的である。

また、この方式では暗号化・複合化ともに並列処理が行えるため、複数プロセッサと相性が良い。

さらに、Niels FergusonおよびBruce Schneierによって推奨される2つの暗号化の一つである。

その他

• CTS(CipherText Stealing)
• 2DEM(2D Encryption Mode)
• ABC(Accumulated Block Chaining)
• IGE(Infinite Garble Extension)
• F8@3GPP

などなど

参考文献

1. Wikipedia - 暗号利用モード
2. triplefalcon - ブロック暗号化モード

パディングモード

暗号化モードでパディング処理が必要であるが、このパディングについても手法がいくつかある。

NoPadding

単純で、パディングを行わないモード これで問題ないのか？

ZeroBytePadding

ブロック長に満たない場合はNULLバイト(0x00)で埋める。 ブロック長ピッタリな場合はパディングされない。

このため、末尾のNULLバイトが本来生成された値の末尾なのかパディングされた値なのかを判断できない。

暗号化するデータにNULLバイトが含まれていない場合に用いれる。

PKCS#5 Padding

ブロック長に満たないサイズの値を表すバイト値で足りない分を埋める。

不足分が変われば埋める値が変わる。

ブロック長がピッタリな場合は1ブロック分丸ごとパディングされる。

RFC1423で規格化されている。

PKCS#7 Padding

バイト シーケンスで構成され、各バイト シーケンスは追加される埋め込みバイトの合計数に等しいバイト数になる。

RFC5652で規格化されている。

.NETではPKCS方式の場合このバージョンが実装されている。

たとえば以下の通り。

FF FF FF FF FF FF FF FF FF 07 07 07 07 07 07 07

ISO10126Padding

W3Cで定義されているパディング方式

ランダムな値で埋める。

たとえば以下の通り。

FF FF FF FF FF FF FF FF FF 7 D 2A 75 EF F8 EF 07

SSL3Padding

SSL Protocol バージョン3.0のセクション5.2.3.2(CBCブロック暗号)で規定されたパディング方式

ANSIX923 Padding

ブロック長に満たないサイズの値を表すバイトを最後につけたNULLバイト値で埋める。

たとえば以下の通り。

FF FF FF FF FF FF FF FF FF 00 00 00 00 00 00 07

参考資料

1. MSDN - PaddingMode 列挙型
2. Pentan.info - [暗号化]ブロック暗号とは(AES/DES/Blowfish PKCS5Padding ECB/CBC IV)

参考資料

1. ネットワークエンジニアとして - Common key cryptosystem / Public key cryptosystem
2. @IT - 第1回　暗号化の基礎
3. 情報社会におけるセキュリティ - ２－４ 暗号化アルゴリズム

ハッシュ化アルゴリズム

暗号化とは似て異なる代物で、暗号化では可逆の暗号文を生成するが、ハッシュでは不可逆の暗号文（メッセージダイジェストとかフィンガープリントとか呼ぶらしい）を生成する。

また、可変のデータ長の平文を一定のデータ長の値を求めることができるため、チェックディジットや、パスワードの保管などに使われる。

使用方法から、ハッシュでは暗号化と異なった特性が求められる。

• ハッシュは同じハッシュ関数を通す場合は常に同じ値が求まる。
• 異なる元メッセージから同じハッシュ値が生成され にくい
• また、生成されたハッシュ値と同一のハッシュ値が生成されるメッセージを求めることが困難であること。

ハッシュ化アルゴリズムの種類

ハッシュ化アルゴリズム一覧

参考資料

1. シニアエンジニアの庵 - ハッシュ関数

ソルト

ハッシュ化アルゴリズムの特性上、同じ平文を与えた場合常にハッシュ化された値は同じになることが保証されている。

この特性をついて、よく設定される平文に対応するハッシュ値をデータベース化し、これと突き合わせることによって平文を求めるという手法（レインボーテーブル）に弱いことが知られている。

この対策のため、平文に「ある値」をつなげた結果をハッシュ化し、「ハッシュ値」とこの「ある値」を一緒に管理するという手法がとられている。

この「ある値」をソルトと呼んでいる。

パスワードの管理であれば、パスワードを入力された後、このパスワードと保管しておいたソルトをつなげハッシュ値を求める。このハッシュ値が保管しているハッシュ値と一致していれば、入力されたパスワードが正しいと判断できる。

また、レインボーテーブルへの対応としては以下の要件を満たすべきである。

• 平文ごとに異なるソルトを使う
• ある程度の長さ（20文字程度以上）を確保する

ストレッチング

ストレッチングは総当たりによる解読の対策として生まれた手法。

ハッシュの使用目的として、処理速度は高速であることが求められるため、この高速性をついて総当たりでの平文探索を行われてしまうことがある。

これの対策として、あえて遅いハッシュ関数を作成するのではなく、早いハッシュ関数を何千回と繰り返すことで処理自体を遅くし、総当たりに時間がかかるようにする手法がストレッチングである。

ストレッチングの回数が多いほど安全性が高まるが、計算量が増えることで負荷がかかってしまう。

この負荷を利用してDoS攻撃に悪用されるリスクが高まってしまう。

参考資料

1. けんごのお屋敷 - 理解してるつもりの SSL/TLS でも、もっと理解したら面白かった話
2. Qiita - 暗号化とハッシュ化に関する基本的な事柄まとめ

Hystrixの機能

Hystrixの機能紹介をしてみる。

• コマンド隔離
• コマンドエラー検知
  • 例外ハンドリング
  • タイムアウトハンドリング
• コマンド同時実行数制限

コマンド隔離

Hystrixではコマンドの隔離が行える。
具体的には、指定したメソッド一つが隔離対象となり、別名で隔離したメソッドと影響しあわないようにできる。

例えば、以下のように2つのコマンドを定義したアプリの場合。 コマンドAからアクセスするAPIAがタイムアウトを頻発するような状況になってしまったとすると、
コマンドAが即エラーを返すようなることで、リクエスト処理スレッドが占有されず、コマンドBは正常に処理が行われる。

コマンドエラー検知

コマンド内で実行される処理でExceptionが発生した場合には、このExceptionを検知してフォールバック処理を行うことができる。

また、コマンド内の処理のタイムアウトを測ることができ、指定時間を過ぎた場合に、HystrixのExceptionを発生させることができる。

timeInMillisecondsの秒数内に、numBuckets分の記録用の箱があるイメージ。 例えば、10,000msで10Bucketsの場合、集計範囲は1,000msになる。

circuitBreaker.errorThresholdPercentageで設定した割合でSuccess以外のエラー数となった場合に、ショートサーキット状態となる。

参考：GitHub - Netflix/Hystrix wiki

コマンド同時実行数制御

隔離されたコマンドは同時実行数の制御が行える。

Hystrixは隔離方式を2種類用意しており、デフォルトでは独立Threadによる制御を行う。

もう一つの制御方法として、セマフォ方式を持っている。

若干飽きて適当になった（ぇ

いったんこれまでにしておく。

Netflixが開発したOSSで、Circuit Breakerの実装。
Circuit Breakerとは、マイクロサービスで開発されたアプリケーション同士が、一つのアプリの障害で連鎖的に障害を発生させる状態を防止するための、ブレーカー的役割をする機能のこと。

後続のアプリケーションが障害を起こした場合、当該アプリで即エラーを返すことでリクエストの流入を抑える。

例えば、一番後続のアプリが障害を起こして、応答がなくなる。

リクエストが流れ続けるため、障害を起こしたアプリを呼び出す前段のアプリが引きずられ、スレッド枯渇やGC頻発による応答不能が発生する（ことがある）。

さらに、これを呼び出すアプリが同様に障害を起こすことで、正常なアプリへの呼び出しも行われなくなり、全体が障害となってしまう。

もし、Hystrixがアプリに組み込まれていた場合。

やはり、最下層のアプリに障害が発生し。。。

しかし、前段のアプリで、障害を検知して後続が障害の場合のロジックを通って

これによって、後続が障害により連続でエラーを返す状態になった場合にも、後続へのリクエストを中止し、負荷をかけないようにしたうえで、異常状態の対処を行う。

これが相当に便利であり、しかも後続への無駄な負荷をかけずにすむという代物でした。

今回はここまで。

1. google analyticsにログイン

2. 新規プロパティを作成

ハマったこと

ウェブを選択。
アプリとウェブだとうまくできなかった（よくよめよ）

3. トラッキングIDをコピー

プロパティのメニューから選ぶ

4. config.toml に追加

baseURL = "https://shibadog.github.io/"
languageCode = "ja-jp"
title = "shibadog site"
theme = "hermit"

googleAnalytics = "UA-999999999-9"

[author]
  name = "shibadog"
:
:

参考

• AGO’s page - hugoにgoogle アナリティクスを導入した話
• なかけんのHugoノート - 画像を追加しよう

3日坊主にならないことを祈る。

しかし、このHugoというやつ結構楽しい。 まずはこれを使いこなせるようになりたい。。。