dockerの削除に関するコマンド覧

初めに

• 学習した内容をアウトプットがてらに書いていこうと思います。

dockerに関するコマンドと解説

docker ps -a

• 使用したdockerコンテナを一覧にして表示する。

• CONTAINER ID / IMAGE NAME /COMMAND / CREATED / STATUS /PORTS　で表示

• STATUSでexitedになっているものは基本的には必要のないcontainerであることが多い。

docker rm

• containerを削除するコマンド

• containerの中はcontainer IDでもimage nameでも良い。

• statuがupになっているcontainerに関しては使えない。

docker stop　

• 動いている containerを止める(exited)コマンド。

• stopした後にはrmコマンドで削除できる。

docker system prune

• exitedとなっているcontainerを全て削除してくれるコマンド。

結語

• 削除はstatusがexitedになっているものしか消せない。

• 削除はrmコマンドまたはdocker system pruneを使用する。

• statusをexitedにするにはdocker stop を使用する。

grepを使用して効率よく目的のフォルダを探してみる

初めに

• 学習したことを上手く活用できたのでアウトプットしていきます。

問題

• dsenv_buildlsフォルダが作成されているか確認するためlsコマンドを使用してディレクトリ内にあるファイルやフォルダ一覧を表示するが多すぎて確認が面倒である。

$ ls

Copying                         ouchien.jpeg.png
Fluid_Grid                      ruby_lesson
HTML_CSS                        web_folder
Resources_Sec09                     令和5年分確定申告書 (1).pdf
Resources_Sec10                     令和5年分確定申告書.pdf
Resources_Sec11                     ターミナル
Resources_Sec13                     スクリーンショット 2024-02-19 20.38.00.png
dsenv_build                     スクリーンショット 2024-02-19 20.38.03.png
file_at_host                        スクリーンショット 2024-03-15 14.17.41.png
git_basics                      スクリーンショット 2024-03-17 15.57.03.png
git_intro                       名称未設定フォルダ
javascript

解決策

• grep -iを使用して条件を設定して検索幅を狭めてみる。

grep | -i dを使用する

• 小文字大文字関係なくdが含まれるものを表示させる。

$ls | grep -i d

Fluid_Grid
dsenv_build
web_folder
令和5年分確定申告書 (1).pdf
令和5年分確定申告書.pdf

grep | -i dsを使用する

• -i dsで小文字大文字関係なくdsが含まれるものを表示させる。

• 上記よりも詳しく条件を記述した。

$ ls | grep -i ds
dsenv_build

結語

• lsのみでは表示されるものが多いのでgrepを利用して選択条件の指定を行った。

• -iとすることで大文字小文字関係なく-i 以降の条件をヒットさせることができる。

マウント先のファイルを確認できなかった件

初めに

• 学習中自らが躓いた部分を備忘録がてらにアウトプットしていきます。

• とても初歩的な問題ですがアウトプットの練習として記述していきます。

dockerにおけるマウントするとは？

• build contextととは別に違うフォルダを設けるとする。

• その別のフォルダーをコンテナのfile systemに取り込むことをマウントという。

問題

• 今回はbuild contextとは別にmounted_folderを作成し、そのフォルダの中にfile_at_hostというファイルを作成する。

• docker fileには以下のように記述する。

FROM ubuntu:latest
RUN mkdir new_dir

• コンテナ内に作成したnew_dirにmounter_folderをマウントし、最後にnew_dirの中にfile_at_hostがあれば良いが表示されなかった。

原因

• build contextであるdockerという名のfolder内にmounter_folderを作成したことが原因。つまり同じ階層でmounter_folderを作成しなければいけなかった。

結語

• マウントするフォルダはbuild contextと同じ階層で作成する。

GitHub Pagesについてまとめてみました！

初めに

• GitHub Pagesについて詳しくまとめてみました。

• 公式ページはこちらになります。

目次

GitHub Pagesとは？

• githubが提供する静的サイトのホスティングサービスのこと。

• 本来はレンタルサーバーなど契約しなければwebページを利用できないが、GitHub Pagesを利用すれば、無料でwebページを公開することができる。

• 静的とはユーザーによってwebページが変更されない、HTMLやCSSで構築されたものを指します。

手順

事前準備

• GitHubのアカウントを取得して無料登録する。

• GitHub上にアップロードするHTMLとCSSを準備する。

流れ(アカウントを作成した前提で進めていきます。)

1. GitHub上で公開するためのリモートリポジトリーを作成する。

2. 作成したリモートリポジトリーに公開するHTML、CSSファイルをアップロードする。

3. ページの公開を行う。

1.GitHub上で公開するためのリモートリポジトリーを作成する。

• リポジトリーはGitHub上でWebページやアプリケーションの管理をする場所のようなもの。

• ホーム画面右上の➕ボタンをクリックして"New repository"をクリック

• リポジトリ名を入力。特にこだわりや理由がなければユーザー名.github.ioで作成する。

• publicにチェックが入っているか確認する。(publicでないとweb上で公開できない。)

• 緑色のCreate repositoryをクリック。

• 表示された画面からREADMEをクリックして何も記載することなく右上にあるCommit changes...をクリック。

• これにてリポジトリの作成が完了しました。

2.GitHub上にアップロードするHTMLとCSSを準備する。

• Add fileをクリックしてCreate new fileをクリック。

• 任意のファイル名をNew your file の部分に記述する。

• 各自が用意しているファイルの中身をコピーして貼り付けを行う。

画像のアップロード

• Add fileからUpload filesをクリック。

• 使用している画像をドラッグ&ドロップしてアップロードを行う。

• アップロードが終了したら、緑色のボタンのCommit changesをクリックすることで保存が完了する。

• もしファイルの変更や、ディレクトリの追加がある場合は、アップロードされた画像まで移動して編集からファイル名の変更を行う。

• 編集したいファイル名をクリック。

• 鉛筆マークのEdit this file をクリックする。

• 赤枠で囲まれている部分でファイル名の変更やディレクトリの追加を行う。

• ディレクトリの追加の例としてはimages(ディレクトリ) / picture(ファイル名)とすることでimagesディレクトリの中にpictureというファイルを入れておくことができる。

3.Git Hubページの公開

• Settingsをクリック。

• pagesをクリック。

• Vist siteをクリック。

• 作成したページが表示される。

  まとめ

  GitHubページの公開までの流れを簡単に説明してきました。 GitHubページを利用すれば無料で簡単にWebページ公開することができます。 もし深く学んでみたい方は公式ページを参照するとより深く理解できると思います。 最後まで読んでいただきありがとうございました。

name属性とid属性について

初めに！

• 学習中に調べた用語をアウトプットがてらに記述していきます。

name属性について

• バックエンドに送信するときに識別するためのもの。

• 全ての要素に必要なものではない。

• 要素によって役割が変わることがある。

• 必ずしも一意性と言うわけではない。

• ほぼid属性と同じ意味。

id属性について

• 対象要素の識別を行うために一意性である必要がある。

• ほとんどの要素につけることが可能なグローバルな属性。

• 同じidを使用することはできない。

• 要素同士を結びつける役割がある。

結語

• name属性は主にバックエンドで使用されて、インプットされた情報い名前つけて識別を行うもの。

• name属性は要素によって役割が変わってくるが、ほぼid属性と同じような役割を果たす。

• name属性は必ずしも一意性でなくても良い。

• id属性は要素の識別を行うので、一意性である必要があり、グローバルな属性である。

• id属性は同じidを使用できない。また要素同士を結びつける役割がある。

git ammend後にエラーが出た

初めに

• 学習中躓いた部分をまとめアウトプットしていきます。

• 初心者にも分かりやすいように書いていきます。

背景

*　リモートリポジトリにpushを行った。

• その後コミットメッセージを修正したいと思い、git commit --amendを実行してコミットメッセージの修正を行う。

• 修正後git pushを行うも以下のメッセージが現れる。

! [rejected]        replace -> replace (non-fast-forward)
error: failed to push some refs to 'https://github.com/kyohei682474/resume.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

1. pushに失敗している

2. 更新が拒絶されている。なぜならあなたのローカルのブランチが遅れているリモートのブランチよりも遅れているから

3. そのリモートの対応する部分。リモートの変更を統合しなさい

4. プッシュする前にpullを行いなさい。

結論

• git push後にgit commit --amendはやってはいけない。

• git amendはコミットを修正して新たにコミットメッセージを書き換えるのでリモートにpushしたメッセージよりも１段階戻してそこから新たにコミットしたことになるのでamendした後にpushをしてしまうと競合が起きる。

解決策

• git resetを行う。

• git reset origin/ブランチ名を実行する。

• 新たにコミットを作成する。

• 新たにコミットメッセージを作成後にpushを行う。

まとめ

• git pushを行った後git amendを行いpushをすることはできない。

• リーカルでresetを行い、amendを行ったよりも前の状態に戻す。

• 他にもあるが今回は一番やりやすい方法で行った。

参考サイト

note.com

git ammend後にエラーが出た

初めに

• 学習中躓いた部分をまとめアウトプットしていきます。

• 初心者にも分かりやすいように書いていきます。

背景

*　リモートリポジトリにpushを行った。

• その後コミットメッセージを修正したいと思い、git commit --amendを実行してコミットメッセージの修正を行う。

• 修正後git pushを行うも以下のメッセージが現れる。

! [rejected]        replace -> replace (non-fast-forward)
error: failed to push some refs to 'https://github.com/kyohei682474/resume.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

1. pushに失敗している

2. 更新が拒絶されている。なぜならあなたのローカルのブランチが遅れているリモートのブランチよりも遅れているから

3. そのリモートの対応する部分。リモートの変更を統合しなさい

4. プッシュする前にpullを行いなさい。

結論

• git push後にgit commit --amendはやってはいけない。

• git amendはコミットを修正して新たにコミットメッセージを書き換えるのでリモートにpushしたメッセージよりも１段階戻してそこから新たにコミットしたことになるのでamendした後にpushをしてしまうと競合が起きる。

解決策

• git resetを行う。

• git reset origin/ブランチ名を実行する。

• 新たにコミットを作成する。

• 新たにコミットメッセージを作成後にpushを行う。

まとめ

• git pushを行った後git amendを行いpushをすることはできない。

• リーカルでresetを行い、amendを行ったよりも前の状態に戻す。

• 他にもあるが今回は一番やりやすい方法で行った。

参考サイト

note.com