八雲技術帳

投稿日 編集日

本文書の目的

完全にポエムです。悩みを書き連ねただけです。

GitLab でも GitHub でも同じことになるのではないかと思います。

この文書に有用な情報は含まれません。

前提条件

  • SIer
  • テスト担当者が存在する
  • 顧客と GitLab を共有できない（ので別の不具合管理表 Excel がある）

お約束事項

プルリクエスト（以下 PR。GitLab ではマージリクエストだが通りが良いので PR と呼ぶ）

運用

基本的な運用フローとして、

バグ発生 →Issue 作成 → 担当者修正 → テスト担当者テスト → リリース

ソースコードの修正フローは

開発者ブランチ →PR→development にマージ → 社内検証環境[develop]→ 客先環境[master]

というフローで開発しているが、Issue の運用がイマイチうまく行っていない気がする。

と言うことでつらい所を列挙する。

＃ただ、元々使っていた Redmine の時に比べれば色々とよくなっているとは思っている。

＃なので Gitlab がダメっていう話では全然ないです。

チケットの Close ＝テスト完了問題

テスト担当者にテスト依頼をした時点で、開発者的にはテストが完了して、さらに

PR もマージ済み。なので、次回リリース時の更新に変更が含まれてしまうが、それまでに

テスト担当者のテストが間に合わないと、開発者のテストだけで客先にリリースされて

しまう。（しまった）。かといって、PR をマージしないと社内の検証環境にも反映できないし、

社内検証環境 → 客先環境のリリースに関門を作るのは負荷的に不可だし…

わざわざ、テスト通ってない Issue の PR を客先リリース前に revert するのもちょっと…

GitLab CI の動画を見ると、PR を自動的にステージング環境にデプロイしてテストすれば OK

PR の画面からデプロイするブランチも変えられるよ！みたいな図になっているけれども、

テスト担当者がブランチの内容までちゃんと理解してないとダメか・・・みたいな状態になっている。

課題管理表との整合性がとれない

顧客とのやりとり用 Excel の内容が GitLab に自動反映されない。

マージ後にわざわざ XLS シートに色々書き込みするとか面倒。何より、Excel シートじゃ

やりとりが全然残らない、検索つらい。なので GitLab で出来るだけやりたいが、同期がつらい。

課題管理表の新しい Issue を GitLab に転記する作業が割と面倒。

これは解決策が簡単で、顧客にも GitLab 使って貰えばいいと分かっているけれども、

担当者に説明するのはしんどい UI してる（なにせ英語。英語の壁は意外と高い）

Markdown がつらい

GitHub フレーバーの Markdown はつらくないが、GitLab の Markdown は純粋な Markdown なので

文章中の改行がそのまま反映されない。文末にスペース 2 個入れて改行か、br タグ書くか

改行を 2 個連打するかのどれかをする必要がある。これがつらい。本当につらい。

元々は GitHub フレーバーだったのになぜ改悪したのか、これがわからない。

というより、Markdown の仕様としてなぜこんな（2 スペース）仕様にしたのか理解できない。

Issue の粒度が揃わない

例えば、同一仕様の画面が 3 個あったとして、（悪い事だけれど）内容はコピペだったとする。

ある人は、画面一個= 1 Issue として 3 個の Issue を切った。

またある人は Issue 本文にチェックボックスを入れて、1 Issue とした。

個人的にはチェックボックスのが好きだけれども、どっちかに揃えたい。これはプロジェクト

開始時にちゃんと話をすれば良かった。という話ではあるけれども。

タグの管理がつらい その１　タグ管理

標準で、GitHub と同じタグが作成されるが、タグの説明がプロジェクトごとなので標準化しにくい。

英語のタグだと分かりづらいので日本語化したタグを全プロジェクトに配りたいが、それは今の所

できない。仕方ないので、手で入れているが、なんだかなぁ。

＃標準のタグのセットみたいなのを定義できるが、既存プロジェクトには反映されない。新規なら反映される？

タグの管理がつらい その２　ワークフロー

ワークフローにあわせてタグを付け外しして欲しいが、周知されておらずタグが適当になっている。

| ステージ | 期待するタグ操作 |
| Issue作成 | bugとか分類タグを付ける |
| 担当者修正 | QAタグ付ける |
| テスト担当者テスト | Issueクローズ |

投稿日 編集日 カテゴリ

動機

家に数台の Docker を走らせる VM が存在している。それをまとめて Web で監視する為に、Portainer を導入した。

Portainer は、リモートの Docker を管理する事ができるが、デフォルトでは dockerd は TCP 経由の API アクセスができない。

これを変更する方法をメモする。

環境

  • Ubuntu 18.04.2 LTS
  • Docker version 18.09.5, build e8ff056 (docker 公式ページの apt リポジトリ使用インストール）

解決方法

解決方法は二つある。 どちらか片方を選択すること（両方やってはいけない）
なお、失敗すると、dockerd が起動しなくなる。

方法その 1

systemd の定義を変更して、 dockerd コマンドラインを変更する（直接指定）

1
2
3
4
5
6
`# systemctl edit dockerd.service

<エディタが開くので以下の内容で上書き>
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// -H tcp://0.0.0.0:2375

方法その 2

systemd の定義を変更して、 dockerd コマンドラインを変更し、JSON の内容を反映可能にする

1
2
3
4
5
6
`# systemctl edit dockerd.service

<エディタが開くので以下の内容で上書き>
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd

/etc/docker/daemon.json を以下の内容で作成する。 ディレクトリ・ファイルが存在しない場合は作成する。

（デフォルトでは存在しない）

1
2
3
{
    "hosts": ["fd://", "unix:///var/run/docker.sock", "tcp://0.0.0.0:2375"]
}
1
2
# dockerd を再起動する
sudo systemctl restart dockerd.service

なぜこんなことをするのか

dockerd の起動パラメタに -H が指定されていると、 /etc/docker/daemon.json に hosts が指定されていると

エラーが発生して起動しなくなってしまうことが原因。

投稿日 編集日 カテゴリ

Apache POI とは

Java 向けの Excel ファイル操作ライブラリです。xls/xlsx 両対応。

公式サイトはこちら https://poi.apache.org

.NET 版の NPOI もあり、ほぼ同じ構成なので同じように当てはまる事象と思われます。

前提として

POI のセルのスタイルの設定方法については以下の Qiita を読んで下さい、

http://qiita.com/unishakoooo/items/58a8c2d3a178c965ee94

Apache POI でセルスタイルを設定すると他のセルにまで適用される

そもそも開けない Excel とは

POI で帳票を作成する際に、セルの罫線などの書式を CellStyle というクラスで扱いますが

これは、Workbook（ワークブック=xls(x)ファイルそのもの)の所有物です。

上記の通り、createStyle すれば新しいスタイルを作って、セルに適用できるのですが、

ワークブック内のスタイルの数には制限があります。

  • xls の場合 4000 個くらい
  • xlsx の場合 64000 個

Excel の仕様および制限 - Excel

https://support.office.com/ja-jp/article/Excel-の仕様および制限-16c69c74-3d6a-4aaf-ba35-e6eb276e8eaa

で、これを超えるとファイルを開く際に Excel がエラーを表示してファイルが開けなくなります。

で、何が問題なのか

workbook.createCellStyle();　するとスタイルが一個作成されます。

例えば、セルの色が黄色なセルが 5000 個あって、全てのセルで毎回 createCellStyle() すると

開けない.xls が出来上がってしまいます。

＃この場合、上記の Qiita の最初の通り、Style のインスタンスを使い回せば何の問題もありません
スタイルのパターンが少ない場合は Style のインスタンスを使い回しする方法でなんとかなりますが、例えば、テンプレートファイルがあって、そこに色を付ける処理をする際は、セルごとに Style を生成するしかありません。そして、色を付けるセルが 4000 を超えると、またしても開けない.xls のできあがりになります。

ではどうするか

セルのスタイルが同じである場合は、CellStyle のインスタンスを使い回すようにして下さい。

・・・。

なんて事をいちいち書いてたら納期遅れか徹夜一直線です。
POI の開発チームは親切にも対策を用意してくれています。

CellUtil.setCellStyleProperty() です

1
2
3
4
5
6
7
8
9
10
11
// 普通に書くとこうなりますが、これだとスタイルが必ず新しく作られてしまう
CellStyle cellStyle = cell.getCellStyle();
CellStyle newStyle = workbook.createCellStyle();
newStyle.cloneStyleFrom(cellStyle);
style.setFillPattern(CellStyle.SOLID_FOREGROUND);
style.setFillForegroundColor(IndexedColors.YELLOW.getIndex());
cell.setCellStyle(newStyle);

// CellUtil#setCellStylePropertyを使えば、同一スタイルをdistinctしてくれます！
CellUtil.setCellStyleProperty(cell, book, CellUtil.FILL_PATTERN, CellStyle.SOLID_FOREGROUND);
CellUtil.setCellStyleProperty(cell, book, CellUtil.FILL_FOREGROUND_COLOR, IndexedColors.YELLOW.getIndex());

まとめ

CellUtil にはこれ以外にも、getRow()など便利なメソッドがあります。

＃素の sheet.getRow()は row がないと null が返るが、このメソッドは自動で新規作成してくれると言うより、個人的見解ですが・・・
POI の *Util(CellUtil 以外にもいくつかあります） にメソッドがある操作は、そっちを使った方が幸せになれます。

＃というか、落とし穴おおすぎー

投稿日 編集日 カテゴリ

Zabbix にデータを送信したかったので調べてみた。

ジョブ件数

完了 redis-cli get stat:processed
103399489

失敗 redis-cli get stat:failed
1143243

デッド redis-cli zcard dead
311
(redis-cli内から実行すると) => (integer) 311

リトライ redis-cli zcard retry
予定 redis-cli zcard schedule

キュー名一覧

redis-cli SMEMBERS queues

  1. “pull”
  2. “push”
  3. “default”
  4. “mailers”

各キューのジョブ数

redis-cli llen queue:キュー名

例）
redis-cli llen queue:default
10

投稿日 編集日 カテゴリ

環境

  • Windows Server 2016
  • VM の OS は Ubuntu 18.04LTS (非 LVM)

何がしたかったか

Hyper-V のデフォルト値で仮想マシンを作成してしまったため、127GB の可変 HDD が作られてしまった。そのため実使用量以上に VHDX ファイルが膨らんでしまっているのでどうにかしたかった。

(実使用量 8GB 程度なのに VHDX ファイルは 64GB になっていた）

操作手順

操作前に VHDX のバックアップを取得しておいた方が無難です。
カジュアルにできる部分もある割に、起動しないと慌ててしまい二次災害が起きやすいです。

VM 上でパーティションを縮小する

縮小はオンラインでは出来ません。（ext4 です）

ファイルシステムの縮小と、パーティションの縮小とに分かれていますが、慣れないことを手でやると事故が起きるので、GParted live USB (iso)を使いました。

（手でやるのであれば、 e2fsck -> resize2fs でファイルシステムが縮小されるので、その後パーティション縮小です）

この時点では、パーティションテーブル等の面倒は Gparted が見てくれるので、縮小後も何事もなく起動できるはずです。

GParted Live https://gparted.org/livecd.php

ディスクの縮小

Hyper-V マネージャから、ディスクを縮小します。この操作は VM が起動している間でも実行可能です。 gdisk コマンドが使用可能な状態で行ったほうが良いでしょう。

シャットダウン状態で行った場合は、起動できない状態になりますので、なんらかの ISO から起動する必要があります。（私の場合は、前述の gparted liveCD を使いました）

ここがポイントで一番書きたかった部分なのですが、ディスクを縮小する際、Hyper-V はパーティションテーブルの面倒を見てくれません。ただし、表示される最小容量はパーティションテーブルを見ているようで、適切な値を表示しているようです。

ディスクの縮小を行うと、gpt ディスクのパーティションテーブルが不整合な状態になります。 この状態で、再起動をしてしまうと、パーティションテーブルがおかしいので、起動できません。これを修正するには、 gdisk コマンドを使って、パーティションテーブルを書き直してもらう必要があります。操作ログは以下です。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
`~$ sudo gdisk /dev/sda
Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.

Warning! One or more CRCs don't match. You should repair the disk!

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged

****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************

Command (? for help): v    # ベリファイしてみた

Caution: The CRC for the backup partition table is invalid. This table may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.

Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.

Problem: Disk is too small to hold all the data!
(Disk size is 41943040 sectors, needs to be 266338304 sectors.)
The 'e' option on the experts' menu may fix this problem.

Problem: GPT claims the disk is larger than it is! (Claimed last usable
sector is 266338270, but backup header is at
266338303 and disk size is 41943040 sectors.
The 'e' option on the experts' menu will probably fix this problem

Partition(s) in the protective MBR are too big for the disk! Creating a
fresh protective or hybrid MBR is recommended.

Identified 5 problems!
Found valid GPT with protective MBR; using GPT.

要するにディスクのサイズがあってない、CRCもおかしい。ということらしい

Command (? for help): p   # パーティション認識できるかチェックした
Disk /dev/sda: 41943040 sectors, 20.0 GiB
Model: Virtual Disk
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): BEE153EA-CA7C-4A4D-A297-B74537528FF5
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 41943006
Partitions will be aligned on 2048-sector boundaries
Total free space is 7339965 sectors (3.5 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00
   2         1050624        34605055   16.0 GiB    8300

パーティションの存在自体は理解しているようだ

Command (? for help): w  # ばっちり正しいのでそのまま書き込んでもらう

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/sda.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.

VM をシャットダウンして VHDX を最適化する

これをしないと VHDX ファイルが縮みません。Hyper-V マネージャから操作可能です。

VM の再起動

祈りながら再起動します。正常に起動するはずです。

お疲れ様でした。

ちなみに

本手順は、ディスク縮小後 VM を起動したまま gdisk したパターン、gparted の Live CD から起動して gdisk を使ったパターンとも検証済みで、どちらも成功しています。

蛇足１

結果、64GB あった VHDX ファイルは 12GB 強まで小さくなりました。

しかし、可能なら固定長ディスクを使うようにしましょう。

蛇足２

ファイルシステムだけ縮小しておいて、最適化して使えばそんなに VHDX が膨れることもないのかもしれないと思いました。どちらにしろオフラインになる時間はできてしまいますが。GUI だとできないので、シェルからコマンドを叩くことになるので事故りそう感はあります。

投稿日 編集日 カテゴリ

はじめに

  • Typescript 初心者です。
  • 既存の javascript のコードに typescript を混ぜ込んでいく時の色々をメモします。
  • tsc とかの導入は省略します。

メモ

document が undefined と言われる。

その .ts ファイルの先頭に

1
declare var document: Document;

を追加する。既に存在する document は Document 型であるという宣言。

Document 型は標準で d.ts を持ってくれているのでそのまま使える。

window が undefined と言われる

1
declare var window: Window & typeof globalThis;

Window 型は標準で d.ts を持ってくれているのでそのまま使える。

globalThis という謎の型は恐らく windows.* には global な変数も入ってしまうので、

そこをどうにかする宣言だと思われる。

document.getElementById(“hoge”) が possible null とか言われる。

  • TS2531: Object is possibly ‘null’.
  • TS2345: Argument of type ‘HTMLElement | null’ is not assignable to parameter of type ‘Element’. Type ‘null’ is not assignable to type ‘Element’.

getElementById に指定した ID の要素が HTML 中に無ければ null が帰ってきてしまうから怒られている。

document.getElementById('hoge')! のように末尾に ! をつけると、null チェックをスルーできる。

…本当はちゃんとチェックするべきでしょうけども。

型に String と書いたものを引き渡そうとしたら警告された

  • TS2322: Type ‘String’ is not assignable to type ‘string’. ‘string’ is a primitive, but ‘String’ is a wrapper object. Prefer using ‘string’ when possible.

string と String は別モノです。 恐らく、 String ではなく string で問題ないはず。

変数の定義を直しましょう。

console.log しようとしたら Cannot find name ‘console’

1
`declare var console: Console;

window にプロパティを追加したいができない

  • TS2339: Property ‘app’ does not exist on type ‘Window & typeof globalThis’.
1
2
3
4
5
6
`declare global {
    interface Window {
	myProperty: any;
    }
}
window.myProperty = console;  // 入れれる

any なのはサンプルだからで、型が解るなら型を入れた方がいい

投稿日 編集日 カテゴリ

環境

  • Ubuntu 18.04
  • Ceph mimic

きっかけ

Ceph のコンソールをみたら、以下のような表示が。

実は一台 OSD のシャットダウンが長いので、強制終了してしまったんですよね･･･

1
2
3
Overall status: HEALTH_ERR
OSD_SCRUB_ERRORS: 1 scrub errors
PG_DAMAGED: Possible data damage: 1 pg inconsistent

修復メモ

まず、今の状態は？とドキュメントを見てみると･･･

http://docs.ceph.com/docs/mimic/rados/operations/health-checks/#pg-degraded

修復は ↓ を見ろ。ということなので飛んでみると

http://docs.ceph.com/docs/mimic/rados/operations/pg-repair/

＼からっぽ／

修復ログ

仕方ないので、ググりながら修復の指示を出してみます。

状態を確認

1
2
3
4
5
root@cephadmin:~# ceph health detail
HEALTH_ERR 1 scrub errors; Possible data damage: 1 pg inconsistent
OSD_SCRUB_ERRORS 1 scrub errors
PG_DAMAGED Possible data damage: 1 pg inconsistent
    pg 6.6 is active+clean+inconsistent, acting [2,3,4]

pg 6.6 （バージョンとかではなく、pg の 6.6 という ID みたいです）がなんか不完全みたいな感じです。

修復指示

1
2
root@cephadmin:~# ceph pg repair 6.6
instructing pg 6.6 on osd.2 to repair

これだけです。 ceph pg repair <pgid> だそうなので、さきほど調べた pgid を入れました。

しばらく待つと、Web のダッシュボードに以下のようなログが流れ、修復されました。

1
2
3
4
5
6
2018-08-13 12:37:13.549087 [INF]  Cluster is now healthy
2018-08-13 12:37:13.549072 [INF]  Health check cleared: PG_DAMAGED (was: Possible data damage: 1 pg inconsistent, 1 pg repair)
2018-08-13 12:37:13.549018 [INF]  Health check cleared: OSD_SCRUB_ERRORS (was: 1 scrub errors)
2018-08-13 12:35:43.367989 [ERR]  Health check update: Possible data damage: 1 pg inconsistent, 1 pg repair (PG_DAMAGED)
2018-08-13 12:20:57.095121 [INF]  Health check cleared: PG_DEGRADED (was: Degraded data redundancy: 15474/372066 objects degraded (4.159%), 10 pgs degraded, 13 pgs undersized)
2018-08-13 12:20:53.583490 [WRN]  Health check update: Degraded data redundancy: 77598/372066 objects degraded (20.856%), 24 pgs degraded, 30 pgs undersized (PG_DEGRADED)

投稿日 編集日 カテゴリ

まえがき

Eclipse 標準で表示を短縮する方法がある。

方法１

設定 -> Java -> 外観 を選択し（設定 -> 一般 -> 外観 ではない)
最終セグメントを除く、すべてのパッケージ名セグメントを圧縮にチェックを
入れて、圧縮パターンテキストボックスに、 “1.” と入力する。
すると com.example.appname.longname.MyPackage が c.e.a.l.MyPackage
と表示されるようになる。(SpringBoot でおなじみの形式)
要するに、最後の部分以外を、 n 文字に縮める。という設定

1
2
3
4
5
`com.example.appname.longname.MyPackage
"0" -> MyPackage   #最後以外表示しない
"." -> ....MyPackage   #最後以外は、"." にする
"1." -> c.e.a.l.MyPackage #最後以外は、先頭1文字だけ表示
"1~." -> c~.e~.a~.l~.MyPackage # 数字以外はそのまま表示される

方法２

設定 -> Java -> 外観 を選択し　（方法１と同じ）
パッケージ名の短縮にチェックを入れる。
ルールテキストボックスに、短縮ルールを記述する。1 ルール 1 行

1
2
com.example.appname.longname.MyPackage
com.example.appname.longname=appname #appname.MyPackageと表示される

まとめ

好きな表示にカスタマイズできるし、わかりやすいという意味で方法２の方が私は好みです。
Eclipse の機能なので、Eclipse ベースの他の IDE でも使えるはずです。
（少なくとも Spring Tools Suite 3.6.4 では使えました）

投稿日 編集日 カテゴリ

環境

  • Fedora 24
  • ZFS (ZFS on Linux) 0.6.5.8 　（以下、ZoL）

問題

そもそも、0.6.5.8 になるまで Fedora24 で ZoL をインストールできなかった。
バージョン上がってインストールは成功するようになって、マウントも正常に出来る。
しかし、再起動すると自動的にマウントされない。

とりあえずの解決策

以下の通りコマンドを実行したらマウントされるようになった。

1
2
3
4
5
6
7
# dmesg中にsplが出力しているhostidが0x000000000 だとマズい？
# これでそれが修正される（が必要かどうかは不明）
dd if=/dev/urandom of=/etc/hostid bs=4 count=1

# なぜかこのあたりのサービスが動いていないようなので enable にする
systemctl enable zfs-import-cache
systemctl enable zfs-mount

参考 URL

https://github.com/zfsonlinux/zfs/issues/2575