コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

dockerコンテナからGitHubへセキュアにアクセスするためのやり方

参照サイトのとおりにやればできるんだけど、仕組みの部分を補遺する形のメモ

やり方

1. GitHubaccess_tokenを用意する

これはgithubのページから設定とかで取り出してください。

Creating a personal access token for the command line - User Documentation

2. 認証情報を環境変数から読み込むファイルを用意する

git-credential-github-token というファイル名で、以下のファイルを作る。

#!/bin/sh

echo protocol=https
echo host=github.com
echo username=$GITHUB_USERNAME
echo password=$GITHUB_TOKEN

これは認証情報の事前埋め込み用の記述で詳しくは「7.14 Git のさまざまなツール - 認証情報の保存」 を参考にしてほしい。

なお、ファイル名は以下のルールで命名規則がなされている。

これはつまり、先ほど説明した一連のヘルパーには、git-credential-cache や git-credential-store といった名前がつくということです。コマンドライン引数を受け付けるよう設定することもできます。 設定方法は “git-credential-foo [args] .” になります。 なお、標準入出力のプロトコルは git-credential と同じですが、指定できるアクションが少し違ってきます。 - 7.14 Git のさまざまなツール - 認証情報の保存

3. Dockerファイルに以下の形で書き込む

使いたいprivateリポジトリがある対象が https://github.com/hogehoge/ の場合以下の通り

FROM ruby

WORKDIR /app

COPY ./git-credential-github-token /usr/local/bin
RUN git config --global url."https://github.com/hogehoge/".insteadOf ssh://git@github.com/hogehoge/ \
  && git config --global credential.helper github-token

4. Dockerを実行する環境に1で取得した情報をセットする

環境変数に情報をセットする

export GITHUB_USERNAME={{githubのユーザ名}}
export GITHUB_TOKEN={{生成したトークン}}

5.認証情報を環境変数に仕込んで実行する

$ docker build .
$ docker run -it -e GITHUB_USERNAME=YOUR_USER_NAME -e GITHUB_TOKEN=YOUR_GITHUB_TOKEN -v .:/app IMAGE bash

docker-composeでやりたい場合は以下

docker-compose build --build-arg GITHUB_USERNAME=$GITHUB_USERNAME --build-arg GITHUB_TOKEN=$GITHUB_TOKEN

しくみ

githubの認証情報を GITHUB_USERNAMEGITHUB_TOKEN の環境変数から読み込むようにし、実行時またはbuild時に環境変数に仕込ませることで利用者が設定した任意のtokenを利用することができる。

参考

Rubyのプログラムでは文字列リテラルはダブルコーテーションで統一したほうがいいのではないかという考え方

かの onkcop には以下のような設定がある

# * 式展開したい場合に書き換えるのが面倒
# * 文章ではダブルクォートよりもシングルクォートの方が頻出する
# ことから EnforcedStyle: double_quotes 推奨
Style/StringLiterals:
  EnforcedStyle: double_quotes

# 式展開中でもダブルクォートを使う
# 普段の文字列リテラルがダブルクォートなので使い分けるのが面倒
Style/StringLiteralsInInterpolation:
  EnforcedStyle: double_quotes

-onkcop/rubocop.yml at master · onk/onkcop

Rubyにおける "' の違い

"(ダブルコーテーション)は式展開するが、'(シングルコーテーション)は式展開をしないというのが大きな違い。

またシングルコーテーションは

シングルクォートで囲まれた文字列では、 \ (バックスラッシュそのもの)と \' (シングルクォート) を除いて文字列の中身の解釈は行われません。 - リテラル (Ruby 2.7.0 リファレンスマニュアル)

とあるように、記号をまま記述したいときだけ有用。

どちらがいいのかと考える

どちらに寄せるほうがいいかと考えたときに、明らかにシングルコーテーションで書きたい場面よりもダブルコーテーションが書きたい場面のほうが頻出する。

そのため、シングルで書いてしまい、式展開するときだけダブルで書き直すという作業が煩雑になるのでダブルコーテーションを使うほうがよいのではないか、という考えになる。

関連リンク

性能テスト、って言いはするけど定義はないのかざっくり調べてみた

無邪気に「性能テスト」って話はでますが、こちらに関しての計測や目標の設定はまちまちなので記載してみた。

性能テストとは

性能テストとは、機器やソフトウェア、システムのテスト(試験)の一種で、要件を満たす性能が出るかどうかを確かめるもの。実際と同じように動かしてみるテストであるため、ほとんどの場合は開発の最終段階に近い工程で実施される。 - 性能テスト(パフォーマンステスト)とは - IT用語辞典 e-Words

とあるように「性能を試すテスト」とされている。

Webシステムにおける「性能」とは

見るべき性能はシステムによって異なるので確認をする必要があるのだが、対象として上げられるのは以下のような要素があげられる。

  • スループット(x秒間にどれだけのリクエストが正常返答できるか、等)
  • レスポンスタイム(一回のリクエストをどれだけのはやさで返せるか)
  • リソース使用量(リクエストに関してのリソースが足りているか)

明確な定義はあるのか

ソフトウェアテスト標準用語集(日本語版)曰く

ソフトウェア製品の性能を判定するためのテストプロセス。

とあり明確にこのようなテストがそれに当たるという言及はないが、種類の説明として「ロードテスト」や「ストレステスト」がそれにあたるとされている。

なお各言葉の意味は以下の通り

ロードテスト

コンポーネントやシステムの振る舞いを測定する性能テストの一種。負 荷(たとえば、同時実行ユーザ数やトランザクションの数)を増加させ、コンポーネントやシステムがどの 程度の負荷に耐えられるか判定する。 - ソフトウェアテスト標準用語集(日本語版)

ストレステスト

予測又は特定した負荷、若しくはメモリやサーバなどのリソースの可 用性が低減したときの限界、又は、それを超えた条件でシステムやコンポーネントを評価するために行 なわれる性能テストの一種。 - ソフトウェアテスト標準用語集(日本語版)

参考リンク

『平成Ruby会議』に行ってきたよメモ

平成Ruby会議 01 | 平成.rb に行ってきたのでそのメモです。

各発表の感想

※資料スライドは見つけたら貼ります。


What is expected?

speakerdeck.com

感想

  • Rubyスクリプトの解析の話
  • トークナイゼーションとかのプロセス、聞いたことはあったが原理を聞くのは初めてだった
  • 概念的に初見で一発理解が難しいジャンルなので、ちょっと触れ合う機会があったら見直したい系統の話

関連リンク


TextbringerでつくるTextbringer

スライドはみつけたら…

感想

  • Emacsとvi系のいいとこどりテキストエディタTextbringerの話
  • Emacsを混沌、viを法と考えるアプローチは生まれてからIDEの権化になってしまった私としてはなるほどという感じだった。

関連リンク

GitHub - shugo/textbringer: An Emacs-like text editor written in Ruby


SimpleDelegator活用のご提案

感想

  • Rubyに標準であるSimpleDelegatorの話。
  • Viewのデコレータじゃないけど、デコレータっぽいことやりたいなって場面で便利そうだなと思ったが、用法用量を守らないと秩序乱れそうとも思った。

関連リンク


ActiveSupport::Concernで開くメタプログラミングの扉

感想

  • いかに短いコードでConcernを実現してるかの話。
  • RubyのメタプロはRubyを使う動機だし、メタプロを理解するには「メタプログラミングRuby」が必読だなというのをひしひしと伝わったので早めに向き合わないとだめだなと思うなど…

関連リンク

メタプログラミングRuby 第2版

メタプログラミングRuby 第2版


Async/Await functions in Ruby

感想

  • GraphQLで遭遇した問題に関して他の言語でも実装されているasync/awaitをどうやってやるかという話とアプローチ。
  • Fiber、そういうのもあるのかという発見。

関連リンク


RubyJVMを実装してみる

speakerdeck.com

感想

  • RubyJavaが動くようにする話
  • 実際に試してみた系ではあるが、JVM実装ってそんな動機でもできるものなんだと思ったし、そこまでやるのがすごいな…と思った

関連リンク


Good to know YAML

感想

  • YAMLのPsychの関係や実装に関して語られたスライド
  • YAMLの仕様は眺めたことがあったが、実際のところどうやってパースしとるねんみたいなところは知らなかったのでざっとした部分でも知れてよかった。

関連リンク


Ruby力を上げるためのコードリーディング

感想

  • Rubyのコード記述力をあげるための方法を紹介するスライド
  • RubyMineのコードジャンプ機能は入れたgemにもつかえることは知っていたが、うまく動かないときがあるのはローカルに入れてないからだと知る

関連リンク


階層的クラスタリングRubyで表現する

speakerdeck.com

感想

  • やってみた系の話、クラスタリングってこういうアプローチでやるんだという知見が得られた。
  • しかし結果として面白くないなどの話を聞くと難しい分野なんだというのを実感

関連リンク


ActiveRecordのpluckメソッドがおかしな挙動をしたので調べてみた

speakerdeck.com

感想

  • 実際にトラブルシュートの内容を実演した感じ
  • トラブルシュートをした苦労話も大変そうだったが、ここまでたどり着く力がすごいなという感想

関連リンク


真のREST

www.slideshare.net

感想

  • RESTとCRUDが混在しがちなので、それに対してちゃんと歴史的な話から含めてのアプローチの話。
  • ここらへんは郡山さんの話も含めて聞くと自分のやっているRESTとは…となるのでオススメ。

関連リンク


breaking change

speakerdeck.com

感想

  • 破壊的変更というものに関してどう向き合うべきか、また提供側としてどうやって考えていくべきかというのを考えさせれらるスライド
  • rubocopをインターフェイス変更のツールとして使うのはさすがという話。
  • ツールの使い方を別のアプローチで使うというのはこうやってやるんだなという感じではある。

関連リンク

全体を通しての感想

  • Rubyの勉強会は個別の技術で濃い話が多くて学びが多いし、技術水準の高さに焦ることが多いが、本当に今回はそれがあった。
  • 今回特に思ったのはRubyをつかってやっていくならメタプログラミングRubyは必読だなと痛感しました。。
  • 会場提供のドリコムさんもすばらしく、運営の皆さんも過ごしやすかったです。

Rubyのモジュールは大文字から始まる必要がある

当たり前の話だが忘れてた

マニュアル曰く

モジュールを定義します。モジュール名はアルファベットの大文字で始まる識別子です。- クラス/メソッドの定義 - モジュール定義 (Ruby 2.6.0)

ありがちな話

Railsにて /tokusyu/201912/special みたいなことを素直にモジュールで書こうとすると出来ないので気をつける。

(こういう場合はroutesでやる)

関連リンク

『マスターデータNight #1』に行ってきたよメモ

マスタデータNight #1 - connpass に行ってきたメモ

各発表の感想

※資料スライドは見つけたら貼ります。

今回のマスターデータの定義

  • アプリケーションが動くのに必須のデータである
  • 運用中に不特定多数のユーザによって変更されない
  • プログラムとは分離されている

「ゲームのマスタデータ特有の3つの困難と、カヤックでの解決方法」

感想

  • 並走で動く、コンフリクト必至のデータ管理に関してどうやって立ち向かっていくかという話
  • ソースコードと同様の確認機構を用いるというアプローチを導入できたのもすごいが、それ以上に差分の可視化を人間にやさしくするツールの提供などがすごいなと思った。
  • マスターデータのチェックに関してGitHubの機構を使おうというアプローチがすごくよかった

関連リンク


DeNAの最新のマスタデータ管理システム Oyakata の全容

Q&A

Q1. リレーション情報設定ってどうやっているの?
A1. oyakata上でリレーション情報を管理している

Q2. 旧タイトルはどうしているの?
A2. 費用対効果などがあるので着手しきれていない

Q3. Git同等機能はどうやってつくっているのか
A3. nomsというデータベースをつかってgit粗糖の機能が使えるのでそれを利用している

感想

  • ほぼ前スライドと同様の問題に関して独自ツールを実装して乗り越えるというアプローチを踏んでいる
  • Git同等の機能を使ったシステムを実現しているのがすごいな…という印象。逆にブランチなどの考えかたは必須なんだろうなという気持ちに。

関連リンク


モンスターストライクのマスターデータのローカライズ運用について

感想

  • 単語のローカライズ変換に対してこういうアプローチもあるんだという事例
  • 同音異句に対する表記ゆれ統一にも使えないかな…と考えてしまった

関連リンク


全体を通しての感想

  • ゲームのマスターデータのぶつかる壁は更新頻度の高さとデータの複雑な関係性だなというのをまざまざと見せつけられた。
  • ただどこも似たようなアプローチで愚直にやっているので、そこに関していい感じのソリューションをOSSで開発できたら盛んになりそうだなとも思った
  • やっぱりインターフェイスとしてのExcel最強論…と思ったらLTで以下の話が

swagger/OpenAPI 3.0で本番と検証用のURLを明示的に示す

ずっと記載分けができないものだと思っていた。

書き方

下記のドキュメントにある。

API Server and Base Path | Swagger

serversというセクションがあり、そこは配列指定できるのでそちらを使う。この書き方にすると、SwaggerUIでもアクセス先切り替えができる。

servers:
  - url: https://example.com/produciton
    description: 本番向けサーバ
  - url: https://example.com/staging
    description: テスト用検証向けサーバ

関連リンク