Dockerチャレンジ1年生(留年)２

※今回は特に備忘録というか試行錯誤と失敗のメモです 前回記事の参考qiita記事に(概ね)従って進めていたが、いくつか止まる

• ローカルとのマウントがうまく行かず、create-react-appコマンドの結果のプロジェクトがローカルにできない。 これはdocker-comporse.ymlとdockefileに記載するディレクトリ名があっていない状態だったので。どちらかがローカルのマウントする側かと勘違いしていた。

正しくはいずれもコンポーネント内のディレクトリで、マウントされるのはdocker-compose run(コマンド指定にcreate-react-appあり)を実行するディレクトリとなるらしい。

該当の記事がdockerの操作とreactアプリケーションの開発開始手順を一度に進めている且つ説明が割愛されている様子？ nodeが乗ったイメージを取得して、containerを作って実行する際に同時に必要なライブラリのインストールとreactプロジェクトの作成を行っている？

dockerFileに一度に記載できないものなのだろうか、と思いつつ本筋は環境構築ではない状態なので、ひとまず飛ばす。

typescriptで作る

その場合は、docker-compose run時に指定しているcreate-react-app に対して --typescript　を付与する。

react-router

react-routerを入れたいなと思い、とりあえずcontainerに直接入りnpm installを実行していたところ時間がかかった。 そしてinstallが完了する前に、containerを止めてしまった。

docker-compose up　コマンドで実行した場合に、docker-compose.ymlのcommandでアプリケーションの開始を指定しており、npm startを止めるつもりでCtrl+Cを押したらcontainerまで止まってしまった…

結局react-routerもrunコマンドに追加して、一応typescriptで動きました。

本当はローカル環境に立てたいのだけど、スペックのあまり良くないマシンだし、macのディレクトリお作法がわからず不要なものを盛々とどこかに残していく状況が嫌で。

次はこれを読む

フロントエンドのコンポーネント設計に立ち向かう - Qiita

Dockerチャレンジ1年生(留年)

世の外出自粛、休業要請の流れを受け、自宅待機中です。

待機といえどなにかしないとな、と思いこれを思い出しました。絶賛留年中ですが…そして色々環境が変わりRubyOnRailsに触れなくなりました。今はReact.jsと戦っているので、ならReact環境をDockerで作りたい所存、と留年記事です。

参考にしているのはこちら knowledge.sakura.ad.jp

blog.web.nifty.com

どこまで続くか…

Dockerチャレンジ1年生 3

とりあえずrailsが動く環境がほしい。 以下サイトを参考に。

【Docker入門】Docker composeでRuby on Rails開発環境を構築する | SPIN OFF(スピンオフ)

docker run -it --rm -v /Users/xxxxx/Work/docker/box_1/app:/app ruby:2.5.3-alpine sh

appサーバの雛形。
macのディレクトリのセンスがいまいちわからない…。

apk add --no-cache --virtual build-dependencies --update \
build-base \
linux-headers \
mariadb-client \
mariadb-dev \
tzdata \
nodejs \
yarn 

開発キット、とのことだが何が何やらなので調べる。

• apk
  Alpine Linuxという軽量なLinuxディストリビューションのパッケージ管理ツール
• apk add --no-cache --virtual build-dependencies ダウンロード時に「--no-chache」オプション付与でインストール時に出るゴミファイルを処理後に掃除
  --virtual は任意の名前（この場合 build-dependencies)を借りの名前として、あとで掃除するときに一括で消せる
• build-base
  （具体的になんのパッケージなのかわからない。公式らしき情報にはMeta package for build base.）
• linux-headers
  ドライバなどのカーネルモジュールをコンパイルするときに必要になる…もの？とのこと
• mariadb-client
  マリアDBクライアント(なんとなく察する)
• mariadb-dev
  マリアDB開発ライブラリ(とてもfatだから注意なんて記事もあったが…大丈夫か

alpine linux+Dockerでmysqlを使用したアプリを作る際に気をつけたいこと - Qiita

• tzdata
  タイムゾーンのデータ
• nodejs
  言わずとしれた
• yarn パッケージマネージャー

cd /app
bundle init
apk add vim
vim Gemfile

Gemfile の修正（gem rails の有効化)
bundle install
railsのインストール（webpack入)
bundle exec rails new . -d mysql --webpack
とここまでやって、exitしたあとappディレクトリを消してしまう(^o^)
再度雛形を作り直して今度はdocker-compose build実行
docker-compose.yamlのコメントが影響していたらしくエラーが。コメントを修正して実行。
初回なのでdb createをさせて、you're on rails!画面が無事表示された。

Dockerチャレンジ1年生 2

とりあえずwebサーバは動いた〜　という所で色々止まる。悪い癖です。
Dockerの仕組みとか構成はググればいくらでも細かい内容が記事になっているので
頭の中で「そっか〜」で終わります。言語化って難しい。

仮想化

仮想化技術に限れば、VMWareのESXiを前職で触れていました。
Dockerのコンテナ型と言われる方式と、仮想化技術の構成が違うらしい。
触れていたと言ってもVMマシン作って消して設定して、という程度なのでお察しです。

• ハイパーバイザー型
  ESXiと呼ばれてるやつなど。WindowsやLinuxなどのホスト上に、
  (VMWareなら)VMWareKernelというカーネルが構成され、そこで物理リソースの管理などを行う。
  (ESXという形式と共通だが、差異はサービスコンソールという管理操作用のUIを
  提供するOSの有無で、ESXiはそれがないため仮想化を支える技術にかかるサイズが小さい)
  そのカーネル上に更に独立した仮想マシンイメージを乗せるイメージ。
  ホストマシン上に仮想化専門のOSがいて、その中で仮想マシンが独立して立ち上がる感じ。

• コンテナ型 ホストOS上にコンテナエンジン？を載せ、一つのOSを区切って共有した仮想イメージが可動する…？
  仮想マシンが自身のOSを個別に可動させる必要が無いため軽量。 ホストマシン上に仮想化専門のアプリケーションを載せて、そいつが一つのOSを共有管理し、
  各コンテナとして分けた領域でイメージが動いている？感じ？

(語彙力=理解力)

イメージ

省略部分も含めチャレンジその1で書いた作業としては、

1. ホストマシン(mac)内にdockerをインストールする(コンテナエンジンが動く)
2. containerコマンドから、起動させるイメージを指定する 現在イメージはローカルに存在しないので、docker hubからダウンロード
3. ダウンロードしたイメージからコンテナーを作成・起動

この時のイメージ・コンテナーというのが、OSを共有しつつ可動する仮想マシンイメージ。

であってる…？

Dockerチャレンジ1年生

例によって色々かじってみる感じで。
とはいえ、Dockerは去年の春にmacを導入してからやってみたいーとmacにインストールまではしていたんです。転職に際してプログラミングの学校に行ってみたら、vagrant+virtualBoxじゃなきゃ駄目って言われて、えええ(;´д｀)となり、仕方なく放置していました。

早速ゴミが消せない問題

で、放置していたらDockerイメージが消せない謎事態。
なにかバージョンが上がった影響か、もしくは自分がファイルを壊してしまっていたのか…でも7イメージ揃って消せない事態は、自分のせいではないと思いたい。

解決方法はこちらを参照しました。

Dockerイメージが「No such image」エラーで削除できない時 - Qiita

docker rmi {イメージ名}:{タグ}

とりあえずwebサーバを作る

こちらの記事を参考に
(もちろん元記事を読んだほうが早いしわかりやすいと思います。あくまで自分の勉強メモです)

Docker で Web サーバを立てて検証環境を作る - Qiita

記載されたコマンドがこちら
$ docker container run --name web -d -p 8888:80 -v $(pwd):/usr/share/nginx/html nginx:alpine
docker containerコマンドは、ローカルにイメージ(上記の場合nginx)がない場合、
DockerHubから自動で取得する。
そのため初回のコマンド実行は少しだけ処理時間が長い。
他のオプション

• run そのまま起動する
• name 起動するコンテナ名
• d コンテナをバックグラウンドで起動する
• p アクセスされるポート、コンテナ内のポート番号を指定（ポートフォワードで接続)
• v ホストの(上記の場合現在位置)パスとコンテナ内のパスをマウントする

このコマンド実行後、localhost:8888接続できる。（ファイルがないのでnginxのエラーが表示される）

とりあえず適当なファイルをhtml以下に配置してみて、表示された、というところまで。

ツイ廃

です。何を突然という感じですが…。
最近TLを覗くのを断っていて、それについて思ったところをメモしてみます。

---

休憩時間が長い

これやっぱり感じます。iPhoneにスクリーンタイムという機能があり、いつどのアプリをどのくらいの時間見ていたか、を記録できるのですが、twitter眺めてる時間が(知らなかったけど)平均3時間以上。立派なツイッター廃人感。 そりゃ時間も長く感じます。
もちろん常識ある社会人なので、仕事中は見ていませんが、トイレに行った時、お昼、買い出しの時、通勤時、家…考えてみればいくらでも見ていました。
で、いざTL監視やめてアプリをフォルダの中に隠蔽して見たところ、休み時間何すれば…と悩むわけでもなくchromeとか開いて面白そうな情報自分で探すんですよね。
これ忘れていたけど意外と大事なアクションだよなあと…。

自分で探す情報

twitterはブロックやらミュートやら、あるいはフォロワーさんフォロー先の方など、自分で情報の取捨選択が行われた状態の情報しか流れてきてないわけですよ。なんかこれ忘れてた感。
仕事で調べ物したときに面白そうな情報サイトだなーとbookmarkしていたサイトを眺めたり、ニュースサイトを色々覗いてみたり。ネットの情報に多かれ少なかれ真偽を疑う余地はあると思うのですが、情報の収集先が複数ある、って大事ですよね…。
あと単純にTLでは見つからなかった情報だって見つかるわけです。当たり前だけど。かなりみみっちいけど、自分そんな興味もってたんじゃん、て極小自己肯定感にもつながる。

他人の情報を受け取らないで済む

TLにはフォロワーさん(あるいはフォロワーさんのフォロワーさんとか、バズってる情報)の私的な考えや暮らし、生き方みたいなのが流れてきますよね。それが楽しいのはもちろんですが、あれ、自分がメンタル駄目な時に見ると、「この人はこんなに正しく生きている」とか「この人はこんなに楽しそうに生きている」とか…あるいは「この人はこんな風に考えているのか、私と違うな…」などと、勝手に解釈して落ち込むんです。本当はどうかなんて分かるわけはないのに。
社会問題の話題で上がるSNSのストレスって多分そういう事なんだろうなあと感じてしまったわけで。
そういう時、手っ取り早いのは遮断かなと、twitter断ちしてみたわけです。断ってる今でも、猫画像投下(これだけは許容する事にした)の時眺めるTLは楽しい。面白い。ユーザである自分の方を合わせる事が大事そうです。

総括

SNSは程々に、自分で手を動かして情報収集をする。
なんですかね。

現場と上層の認識齟齬の話

知り合いにも、自分にも、聞く話として「上層が現場と全く異なる対応をされる」というのがある。
「人手が足りない所に人をよこさず、人が足りている所に人をよこす」とか、「必要な知識のある人が必須なのに新人をよこす」とか…。
事件は会議室で起きているんじゃない、じゃないけど、下の位置に居る身としては、「どうせ上層部は現場のことなんかわかっていないんだ」でなんとなく乗り越える？耐える？傾向にある。
ここから書くことは、あくまで主観に偏っているし、現場次第の点も多い、偏見に満ちた内容かもしれないので、その点はご了承いただきたい。単に頭の中を整理してみたくなっただけで。

問題提起時

ケースとして前提とするのは、あくまで、「下から上に問題が提起される」場合。
「現場でなにかしかの支障が出ている、出る可能性が高い」状態。かつ、「現場の権限や仕組みでは対処が難しい時」（金・物・人）。逆に言えば、現場を仕切っているのは下の人間で、それでいて、権限が足りない状態の時。下位組織として独立性が足りていない時、なのかも。

問題提起の内容

「〜という問題があるんです」ということを上層に相談した時「ではこうしよう」と適切な対応をしてくれる組織ならそもそも問題はない。支障があるのは、「下が期待した状態にならない上層の対応」になる。
ここで、「下が期待した状態」について考えてみる。
考えるに、２つのパターンがあると思う。

1. 「〜という問題があります」という提起しかない場合。
   この時、上の反応としては、以下の2つが考えられる。
   ・「では〜という解決策をとろう」と自らの権限と視点、最善であれば、更に下位の組織の状態を調査して客観的な情報を以て、対応策を提示する。
   ・もう一つは、「で？」という反応。つまり、問題に対して解決策を見つける立場ではない、という認識である場合。自身の領分は、あくまで決定権であり、選択肢を提示するのは問題提起をした下位組織自らであるべき、といいう考え方。
   正直、上層の立場によるが、どちらも正しい視点のような気はしている。問題に対しての解決策は、結局現場の人間が一番問題の情報が多いので提示しやすい。もしそれができないのであれば、解決策は「それ専門の組織」が請け負うのがベストなのかもしれない。
   組織の構造によると思うけど、自分の所属する一番大きな母体ではなく、問題解決を専門とする部署に相談をする。それが専門家であれば、上層（この場合母体）の判断も柔軟になる可能性もある。

2. 「〜という問題があります」に対して、下が「〜という対応を求めています」と明確にしているケース
   この場合、下が「上層はどうしようもない対応しかしない」という認識をするパターンは、上層が下のいう「〜という対応」に答えられない場合。または、「〜という対応の効果が伝わっていない」ため対応しない、別の対応をしてしまう場合。
   前者の場合、上層に必要なのは「それが無理である」という根拠、そして可能なら代案の提示。（問題が問題である、という認識がされていないのは、前者も後者も前提として論外だと思う）後者の場合は、下の人間の方にも問題がある可能性も高い。問題というか…それこそその階層だけでは難しい状態というか…。後述する、専門組織とか専門家が居れば、そこに頼りたい。
   もう一つ、上層がやりそうな「期待はずれ」としては、「〜という問題の真の原因はこれだ」と、字面通り「見当はずれ、期待はずれ」な解決方法を、相談もなく実行してしまうパターン。「本当の問題はどこか」という観点は、問題解決の話の中では多分頻出する観点だと思うし、大事だとは思うんだけど、それを実態とかけ離れたところで勝手にやってしまう、というケースが有りうるのが厄介。現場の人間の介入を絶対にしたいところ…。

解決方法の模索

結局立場が変われば、見えるもの、見たいもの、見たくないもの、見えないもの、が変わってきてしまうことは前提にあると思う。組織として一番共通の認識を持ちやすいのは「金額」かなとも思う。
問題解決を促すアプローチは、やはり対費用効果の額面を明確にできるかどうか、かもしれない。人が足りないことで発生するコスト、ものが足りないことで発生するコスト…。
まあそんな物まとめる時間ねえよ！って人が多いのだろうなとも思う。
問題解決の専門部署っていうのは、結構必要なのでは？などと思い始める。当事者VS当事者では、対立の構図は濃くなる傾向がありそうだし。中間管理職ではないが、正しい場所に相談する、正しい情報を整理する、といった作業も、多分専門技術だと思う。
できれば3つの立場（問題提起者、権限を持つ層、情報を取り持つ人）が居るのが、問題解決の場所には有用なのかなと。

まあ、世の中にはどんなに数字を持ってきても、頑としてマイワールドの視点から抜け出せない上層も居るし、上層に対して偏見で凝り固まった作業者だって居る。解決は難しい。