ゼロからDockerを学んでみて
はじめに
Dockerとは、コンテナという技術を使って、同じ開発環境を他人と確実に共有できる便利な技術。
基本の3要素
超ざっくりした流れ
Docker fileにOSとかinstallしたいものを書く
Docker fileからdocker buildして、Docker imageを作る
Docker imageからdocker runしてコンテナを作る
Dockerfileの書き方の基本
FROM
ベースとなるイメージを決定：基本はOSを指定する（ubuntu, alpineなど）
RUN (Layerを作る)
イメージを構成するLinuxコマンドを実行する
RUN (Layer) 数は&&を使う、バックスラッシュを使って改行などをして最小限にする
CMD (Layerを作らない)
デフォルトのLinuxコマンドを実行する、CMDは一つだけ
COPYとADD
ホストからコンテナにファイルやフォルダを移動することができる
COPY
基本使うのはほぼこっち
ADD
tarの圧縮ファイルをコピーして解凍したい時
CMDとENTRYPOINT
ホストからコンテナにファイルやフォルダを移動することができる
CMD
docker runの時に上書きできる。ENTRYPOINTがあった場合はENTRYPOINTの引数を持ってくる
ENTRYPOINT
docker runの時に上書きして欲しくない時はこっちを使う、run時に上書きできない
Docker daemonとは
結構よく出てくる用語。dockerはCLI(Command Line Interface)を使ってdocker daemonに命令を送って実行してもらう。
学習中よく使ったコマンド
docker ps -a
docker ps (process status) -a (all) はContainerを表示するよく使うコマンド
docker run -it
コマンドオプションの-itを使うとインプットが可能になってprettyになる
-i: インプットが可能になる。
-t: コマンド表示がprettyになる。
バックグラウンドとフォアグラウンド
バックグラウンド (-d = detached：切り離された) モードとフォアグラウンド (--rm) モード (使い終わったら消える)
docker run -v (volume)
Containerからホストのファイルシステムにアクセス (マウント) できるようにするオプション
高度なスクリプト、データなどはContainerには置かずに、実行する時、ContainerからHost環境にアクセスする。
docker run -p
PublishのPだけど、PortのPって覚えてもOK
複数のWebサービスを立ち上げた場合、それぞれのWebサービスにポートを割り当てる必要がある。
-pコマンドを使って、ホストのポートからContainerのポートにパブリッシュ（ポートを指定、アクセス）する。
番外編 Juyter Lab
ブラウザ上で動くPythonの総合開発環境：IDE(Integrated Development Environment)
データサイエンスで使う。
おわりに
最初は、dockerという概念を理解するのが大変でした。ただ構築環境を作り上げるのは楽しかったです。プログラミング言語もそうだと思いますが、先は果てしなく長いと思うので、着実に学んでいきたいと思います。
HTML CSS メモ その１
はじめに
HTML CSSを学んだ時のメモです。
レスポンシブWEBデザイン
デバイスの表示領域によって、Webページの表示を切り替える。
グリッドレイアウト (Grid)
グリッドを可変にするレイアウト。
そもそもグリッド（grid）とは？
gridとはもともと、肉をgrillするための「(鉄製の)焼き網」のことです。 線が縦横にあっても、縦線のみでも、横線のみでもgridです。 gridは「(鉄)格子」「(窓の)鉄柵」「(地図の)碁盤目」「(高圧線の)送電網」などと訳されます。
フルードグリッドは、ピクセル数を固定した指定ではなく比率で指定することにより、デバイスの幅に対して柔軟にレイアウトする手法です。
FLEXBOX
文字通り、柔軟な箱としてレイアウトする。
flexboxは、とりあえずこの2つは覚えておく。
シンプルな画像の横並び
両端揃え（justify-content: space-between）
タグについて
sectionタグ（文章）
目的は文書の意味を明確にすること。
デザインやレイアウトの目的で使用すべきではなく、そのような目的では
コード作成から、GitHub Pagesで公開するまでの流れ
はじめに
ローカルでのコード作成から、GitHub Pagesで公開するまでの流れをまとめました。
ローカルで作成したコードをリモートリポジトリに上げる
ディレクトリ作成、git initする
mainブランチから作業ブランチを切る
(git checkout -b branch_name)作業する
ファイルをaddする
(git add)ファイルをcommitする
(git commit)リモートにファイルをpushする
(git push origin) pull request を作成
reviewを依頼する
修正がある場合は修正する
approveをもらったらリモートのmainにマージする
ローカルのmainブランチをリモートの最新と一致させる
(git pull origin main --rebase)
GitHub Pagesを使ってサイトの公開
画面上部の横列の一番右の「Settings」というリンクをクリック
Settingページの左側にあるメニューの中から「Pages」をクリック
GitHub Pagesの項目の下に「Your site is live at ...」と表示されている場合には、そのURLですでにWebページが公開済
もし表示されていない場合には、「Branch」の項目が「None」なので、デフォルトブランチに変更して「Save」ボタンを押す
これで自分のWebページをインターネット上に公開するための作業は終了
git push エラーが出た場合
[rejected] main -> main (fetch first)というエラーが出ました。
言われた通り、fetchして
(git fetch origin main)
git pull origin main --rebase
をしてからpushしたら無事にpushできました。
おわりに
GItHubはプログラミングを使う上での必須スキルだと思います。
自分がわからなくて詰まった箇所など、こういったメモを残して、
再確認できるよう繰り返し学習を進めていきたいと思います。
GItHubのQuick Setupをすっ飛ばしてしまってmainブランチが消えた時のメモ
Quick Setupをすっ飛ばしてしまってよくわからなくなり、
git branchをしてもmainブランチが全然出てこなくなりました。
最終的にはリモートからfetchしてorigin/mainとmergeしたら出てきてくれました。
git init
まずはリセットする。
git remote add origin https://github.com/リポジトリ名
リモートリポジトリと繋ぐ。
git branch -M main
masterからmainに名前変更する。
git fetch origin main
ここでリモートリポジトリ(origin)をローカル(main)に持ってくる。
git merge origin/main
これでローカルmainにmergeする。
git branchをすると無事mainブランチが出てきてくれました。
Learn Git BranchingでGitコマンドの練習
はじめに
Learn Git Branchingという無料でGitコマンドを練習できる素晴らしいサイトがあります。
こちらで学習してみて、印象に残っているGitコマンドをメモがわりにまとめました。
よく使ったコマンド (Main編)
git checkout -b bugFix
bugFixブランチを作って、bugFixブランチにcheckoutする。
git branch -f bugFix c2
bugFixブランチをc2に強制移動させる。
git cherry-pick
現在の位置(HEAD)の下に一連のコミットをコピーしたいという意を単純に表す方法。
git commit --amend
直前のコミットを修正する。
git rebase -i
コミットの順番を変更する
git tag v1 c1
v1というtagをつける。
相対リファレンス
ハッシュでコミットを指定できるが、相対リファレンスという便利な機能もある。
・一つずつ上へ移動させる^（カレット）
・複数回上へ移動させる ~
よく使ったコマンド (Remote編)
git clone
既存のリポジトリをローカル環境に複製する。
git fetch
リモートにあってローカルリポジトリにないコミットをダウンロードする。
git pull git pull --rebase
リモートの変更を取って(fetch)してマージする。 リモートの変更を取って(fetch)してリベースする。
git rebase side1 side2
side1（親）side2（子）でrebaseする。
git checkout -b side o/main
sideという名前で、o/mainを追跡するブランチを作成して、checkoutする。（激ムズ）
おわりに
最後まで解けなくて答えを見てしまった問題もありましたが、良い勉強になりました。
Gitというものに対して、
「よくわからない」
から
「なんとなくわかった」
に変えてくれた、とてもいいエクササイズでした。
Git初学者の初めてのGit その2
Gitのデータをどうやって管理しているか
Gitは圧縮ファイルをスナップショットで記憶していく。（変更したファイルの差分を記憶する形ではない。）
スナップショットとして記憶することで、バグが起きた時など以前の状態に戻すことが容易である。
ローカルリポジトリは3つのエリアに分かれてる
①ワークツリー（手元の作業場） ここでファイルを変更する。 変更したいファイルだけステージに上げる。（git addコマンド）
②ステージ コミット（スナップショットを記録する）の準備の場所
③ローカルリポジトリ スナップショットとして「圧縮データ」「ツリー」「コミット」ファイルを記録する。（git addコマンド）
ブランチについて
複数人が並行して機能開発するためにあるのがブランチ。
他の人の開発の影響を受けないのがブランチの利点である。
開発、コードを変更（どんどんコミットを重ねる）中で、コミットが枝分かれしていく。
ブランチは枝そのものではなくて、コミットについたタグ（ラベル）であり、コミットIDを指し示すポインタ。
HEADとは今自分が作業中のブランチへのポインタ。
ブランチを利用していく上で、基本的な考え方
mainブランチはリリース用ブランチ
トピック毎ブランチは開発用ブランチ
として進めるのが基本、masterブランチは常にリリースしているものと同じにする。
プルリクエストについて
自分の変更した内容を相手のリポジトリに取り込んでもらえるように依頼する機能
リベースについて
変更を統合する際に、履歴をきれいに整える。
他のブランチでの変更分を自分のブランチに取り込みながら履歴を整えることができる。（fast forward）
git rebase <ブランチ名>
リベースとマージの違い
どちらも枝分かれしたコミットを取り込む動作。
違いは取り込んだ履歴が枝分かれするのか？一直線なのか？の違い。
リベース（作業の履歴を残しときはこっち）
・コンフリクトの解決が比較的複雑になる
・履歴が理解しやすい
マージ（履歴を残さなくてもいい、履歴をきれいにしたのはこっち）
・コンフリクトの解決が比較的簡単
・履歴が複雑化しやすい
注意：GitHubにプッシュしたコミットをリベースしてはいけない。
一つの考え方として、
プッシュしていないローカルの変更には、リベースをする。
プッシュした後は、マージをする。
（コンフリクトしそうならマージ ）
スタッシュコマンド（stash：へそくり）とは
今している作業を辞めて、違う作業をしなくてはならなくなった時、
今している作業の変更分を一時避難させることができる。
後で呼び戻すことができる。
Git Hubを使ったリモートリポジトリとのやりとり
git remote add origin <URL> originというショートカット名で、<URL>のリモートリポジトリを登録する
リモートの情報を詳しく知りたい時
git remote show <リモート名> git remote show origin
リモートを名を変更
git remote rename <旧リモート名> <新リモート名> git remote rename old_name new_name
リモートリポジトリとの接続を削除（解除）
git remote rm <リモート名> git remote rm origin
