npxが便利だった
最近またNode.js
を触ってる。
npm
で色々インストールするときに、そのプロジェクトでしか利用しないものは、やっぱりグローバルな領域にはインストールしたくない。
けど、そうするとnode_modules/.bin
にPATHを通すとか一回り工夫しないといけなくて、地味にめんどくさかった。
npx
はその辺りを上手くやってくれるツールっぽい。
npx パッケージ 引数
みたいに実行する。
色々できそうだが、今のところはコマンド呼び出しにしか使ってない。
gitのpush.defaultをcurrentにした
pushが楽だからという理由で設定を変更した。
currentとsimpleの違い
push.default
のデフォルト値は過去に変更されたことがあって、2.0以降だとsimple
になっている。
simple
はupstreamが設定されていて、同名の場合にプッシュ先を省略できる。
current
は同名のブランチだけをプッシュする。upstreamが設定されていなくても良く、リモートリポジトリにブランチがなくても良い。
自分の使い方
gitのブランチの作成はローカルでやる派なので、何か新しいissueに取り掛かる時には、
$ git checkout -b do-something
として、ローカルでブランチを作成する。一通り作業が終わったら、
$ git push -u
とする。
simpleとは違ってブランチ名を指定しなくてもプッシュができるだけなんだけど、地味に便利。
vcs_info
の都合で-u
を使ってupstreamを設定しているが、無くても問題ない。
異動した
先日病気をしてからの体調面のこと、幸いに受け入れてもらえるチームがあったこと、などいろいろあって異動することにした。
以前の部署では、休んでた期間を除いて一年強と短い期間ではあるが、複数チームが関わる大きなプロダクトに携われたことは、とても良い経験になった。
今日からはスモールチームでやっていく。規模感は前とは全然違うが、その分自分が関われる範囲は広いだろう。それに自分の実力が成果に直結することになるので、今まで以上にちゃんとしてないと。
とはいえあまり意識高い感じでこじらせるとしんどいんで、良い感じでパフォーマンス出せるようにがんばろう。
zshでGitのリモートリポジトリのホスト名を表示する
zshではvcs_info
を使用して作業中のリポジトリの情報を表示することができる。「zsh vcs_info」でググるといろいろと出てくるが、私は以下の記事をベースに設定を行って、少しずつアップデートしている。
zsh の vcs_info に独自の処理を追加して stash 数とか push していない件数とか何でも表示する(記事は4年ほど前のものだが、zsh自体がそんなにアップデートしているわけでもないので、今でも十分通用する)
最近になってgithub.com
とgitlab.com
のどちらも使用するようにしたので、リモートリポジトリを間違えないようにホスト名を表示できるように修正した。
リモートリポジトリのホスト名を取得する
git ls-remote --get-url
でリモートリポジトリのURLを取得できる。このURLは.git/config
に記載されているものが表示されるようになっている。たぶんgit remote add origin REMOTE_REPOSITORY
で設定したものと同じになるはず。リモートが複数設定されている場合にどうなるか未確認だが自分のユースケースではそれはあまりないので、気にせず使っている。
git@github.com:kawaken/dotfiles
という構成になっている場合が多いので、:
と@
で分割してホスト名に該当しそうな箇所を拾っている。
hostname=$(git ls-remote --get-url | cut -d: -f1 | cut -d@ -f2)
プロンプトに表示する
自分の場合はhook_com[branch]
の中に混ぜ込むようにしている。
https://github.com/kawaken/dotfiles/blob/master/zsh/vcs_info#L54
- echo "%f${arrow}%F{cyan}${remote}%f${(j:/:)gitstatus}" + echo "%f${arrow}%F{cyan}${remote}(${hostname})%f${(j:/:)gitstatus}"
最終的にはこんな感じで表示される。
出力結果が長い
ホスト名が出るのは良いが、ちょっと長いので短くしたい。ここで以前書いたホスト名を短くする手法を使う。SSH_CONFIGを使用してgitのリポジトリURLを短縮する
# gh = git@github.com git remote rm origin git remote add origin gh:kawaken/dotfiles git branch -u origin/master
シンプルな表示になった。
GitLabCIの結果をGitHubにコミットする
hugoで生成したHTMLをコミットしたかったのでやってみた。
SSHのキーペアを作成する
既存のものは使い回したくないんで、新規に作成する。
$ ssh-keygen -f id_rsa_gl2gh
作った鍵は以下のように使用する。
GitHubでのDeploy keyの設定
コミットしたいリポジトリの設定から、作成した公開鍵をDeploy keyに追加する。 追加したあと、SSHで接続の確認をする。
$ ssh -i id_rsa_gl2gh git@github.com PTY allocation request failed on channel 0 Hi kawaken/kawaken.me! You've successfully authenticated, but GitHub does not provide shell access. Connection to github.com closed.
普段使っている鍵と違い、ユーザ名と特定のリポジトリ名が表示されている。
GitLabCIのVariableの設定
GitLabCIでは実行中の環境変数を外部から設定できるようになっている。プロジェクトのSettings -> CI/CD
のVariableの設定に、Key/Valueの組み合わせを登録する。
Key名をSSH_PRIVATE_KEY
にして、秘密鍵を登録する。
UI上は短い一行の値しか入力できないように見えるが、複数行の内容でも問題なく設定できる。
GitLab CIの設定
Using SSH keys with GitLab CI/CD | GitLab におおまかな手順は載っているが、ちょっと修正が必要になる。
自分は以下のような設定になった。
before_script: # SSH用のディレクトリ作成 - mkdir -p ~/.ssh - chmod 700 ~/.ssh # github.comのSSH host keysを保存する - apt-get update -y && apt-get install openssh-client -y - ssh-keyscan -t rsa github.com >> ~/.ssh/known_hosts # ssh-agentの設定 - eval $(ssh-agent -s) - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add - > /dev/null # git のユーザ情報設定 - git config --global user.email "user@example.com" - git config --global user.name "Kentaro Kawano" to_github: stage: build script: - rm -fr public - git clone git@github.com:kawaken/kawaken.me.git public - hugo - cd public - export MESSAGE="update $(date +'%F %T')" - git add -A . - git status - git commit -m "${MESSAGE}" - git push origin master only: - master
更新対象のリポジトリをhugoの出力ディレクトリとし、変更をすべてコミット&プッシュするようにした。
git status
を途中で実行しているのは、何が対象となったかをGitLabのJobのログに残したいため。
SSH_CONFIGを使用してgitのリポジトリURLを短縮する
gitのリポジトリにSSHでアクセスするときに限るがSSH_CONFIG
を使用することでホスト名を簡略化でき、リポジトリURLを短縮することができる。
SSH_CONFIGでの設定
例えば以下のようにする。
Host gh User git Hostname github.com
cloneする
git@github.com:kawaken/repositry.git
短縮して、
gh:kawaken/repositry.git
となる。さらに最後の.git
は無くてもいいので、最終的にコマンドは以下のようになる。
git clone gh:kawaken/repositry
ちょっとだけ便利。
ちなみにSVNでもこのテクニックは使える。
DynamoDB Local(Amazon公式)のDockerイメージを使う
先日の8月22日に、Amazonから公式にDynamoDBのDockerイメージが公開された。
ググっても野良のイメージしか出てこないのでまだあまり認知されてないっぽい。
ちょうどDynamoDB Localを利用していたところだったので、早速試してみた。
とりあえず立ち上げる
$ docker run --rm amazon/dymamodb-local Initializing DynamoDB Local with the following configuration: Port: 8000 InMemory: true DbPath: null SharedDb: false shouldDelayTransientStatuses: false CorsParams: *
jarで配布されていたものと同じっぽい。
オプションを使用したい
とりあえず開発時のテストとはいえ、データを永続化したい。
jar版では起動時の引数で設定することができたので、Dockerイメージにおいても引数を渡せれば設定できるはず。 Dockerfileは見当たらないので、とりあえずinspectしてみる。
$ docker inspect amazon/dynamodb-local:latest (snip) "Config": { "Hostname": "", "Domainname": "", "User": "dynamodblocal", "AttachStdin": false, "AttachStdout": false, "AttachStderr": false, "ExposedPorts": { "8000/tcp": {} }, "Tty": false, "OpenStdin": false, "StdinOnce": false, "Env": [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" ], "Cmd": [ "-jar", "DynamoDBLocal.jar", "-inMemory" ], "ArgsEscaped": true, "Image": "sha256:6901b80d033a1d94e1283711be031f2657d90edf0768118bb22c952feba780bd", "Volumes": null, "WorkingDir": "/home/dynamodblocal", "Entrypoint": [ "java" ], "OnBuild": null, "Labels": { "aws.java.sdk.version": "1.11.119" } }, (snip)
- Entrypoint: java
- Cmd: -jar DynamoDBLocal.jar -inMemory
となっているので、docker runの際に javaのオプションとなる部分をすべて指定することで設定を変えられそう。
データを永続化する
dbPathでパスを指定することができるので、Volumeを指定してそこにデータを置くようにする。 ひとまずフォアグラウンドで起動する。
$ docker run --rm -p 8000:8000 -v ~/dynamodb-data:/home/dynamodblocal/data \ amazon/dynamodb-local -jar DynamoDBLocal.jar -dbPath /home/dynamodblocal/data Initializing DynamoDB Local with the following configuration: Port: 8000 InMemory: false DbPath: /home/dynamodblocal/data SharedDb: false shouldDelayTransientStatuses: false CorsParams: *
別のターミナルからawsコマンドを使用し、テーブルを作成してみる。
$ aws dynamodb create-table --table-name Clients \ --attribute-definitions AttributeName=id,AttributeType=S \ --key-schema AttributeName=id,KeyType=HASH \ --provisioned-throughput ReadCapacityUnits=1,WriteCapacityUnits=1 \ --endpoint-url http://localhost:8000 { "TableDescription": { "TableArn": "arn:aws:dynamodb:ddblocal:000000000000:table/Clients", (snip) } }
一覧で取得できるか確認。
$ aws dynamodb list-tables --endpoint-url http://localhost:8000 { "TableNames": [ "Clients" ] }
ホスト側のデータ保存先に指定した場所を確認してみる。
$ ls ~/dynamodb-data AKIAIOSFODNN7EXAMPLE_ap-northeast-1.db
この中にデータが入ってそう。
まとめ
DockerイメージでのDynamoDB Localの動作確認ができた。
Javaの環境を用意しなくても動作ができるので、気楽に利用できるようになった。ありがたい。