Skip to content

Instantly share code, notes, and snippets.

@japaslu
Last active December 24, 2019 07:40
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save japaslu/6c47da446bee3ca626279e0ebce58495 to your computer and use it in GitHub Desktop.
Save japaslu/6c47da446bee3ca626279e0ebce58495 to your computer and use it in GitHub Desktop.
ラボノート

メリット

コンテナはKernelやベースOSの機能を共有するため、OSの全機能を乗せる必要がない

「ただし」
Linuxのベースイメージを基盤にしているのでホストOSは、その派生である「ubuntu」や「centOS」などしか使えない。
※Windowsの中でLinuxの仮装OSを立ち上げ、その上でDockerを使用する「Docker for Windows」という仕組みも存在する。

VMに比べて、リソース消費量が少ない

「ただし」
サーバ仮想化製品なので、VMに比べるとリソース消費量が少ないだけで、ベースOSに直接アプリを立てたほうがリソース消費量は少なくなる。

開発のスピードが上がる

集団で開発する場合、個々の環境に左右されにくくなるので品質が安定しやすい。
開発者が開発するための環境を用意するには、ハードウェア、ソフトウェアの調達や設置場所の考慮など様々な要因に対する検討が必要となるが、Dockerであれば少ないリソースで必要な開発環境を素早く揃えることが出来る。

問題が発生しても、他のコンテナに影響が出ない

個々でホストOSとして完結しているので、他のコンテナに影響が出ない。

カーネルをすべてのコンテナで共有するため、カーネルに対する構成変更操作は個別に行うことが出来ない




デメリット

大規模になれば重い

VMに比べて、リソース消費量が少ない」の項を参照。
大規模になればなるほど、小さかったリソース消費量も大きくなる。

コンテナを細分化しすぎると複雑になる

一つの動作に一つのコンテナなんて作ってると、コンテナだらけになる。
問題の原因箇所も分かりづらくなってしまう。
「ただし」
大規模なサービスはDockerを使わなくても複雑な状態になってしまう。

フルスタックエンジニアが必要

使いこなすには相応のシステム管理と高度な統合的スキルが必要

本番環境で、安全かつ確実な方法でDockerを動作させるには、多くの変数を慎重に管理する必要がある。

  • セキュリティで保護された、非公開のイメージリポジトリ (index)
  • 組織的にコンテナのデプロイをダウンタイムゼロで実行
  • 組織的にコンテナのデプロイをロールバックする
  • 複数ホスト間のコンテナのネットワーキング
  • コンテナログの管理
  • コンテナデータの管理(dbなど)
  • initやログを正しく扱えるイメージの作成
    などなど

バグが存在している

安定が求められる本番環境には向かない。


まとめ

いつ落ちても支障がない事を前提に

  • 複数の環境で使うか
  • 頻繁に変更するか
  • 増えたり減ったりするか

の内、2つ以上当てはまるならコンテナ化を検討したほうが良い。


参考

  1. 次世代ソリューション企画案
  2. Dockerのメリット・デメリット
  3. Dockerにまつわる誤解とベストプラクティスについて
  4. Dockerの本番運用
  5. マイクロにしすぎた結果がこれだよ!
  6. 「それコンテナにする意味あんの?」迷える子羊に捧げるコンテナ環境徹底比較 #cmdevio2019
  7. [翻訳] Dockerについてよくある勘違い
sudo vim /etc/ssh/sshd_config
portの変更
PasswordAuthentication → no
#パスワードを入力してsshする方式は攻撃の対象になりやすいので無効化
PermitEmptyPasswords → no
#上の行でパスワードログインを無効化しているのでそもそもパスワード入力しようとするとエラー出ると思いますが、念の為明示的に
PermitRootLogin → no
#サーバのすべての設定を変更ができるrootアカウントでssh接続するのを拒否するため
PubkeyAuthentication → yes
sudo systemctl restart sshd
sudo sshd -t
元に戻す
git checkout HEAD
ナノ
Ctrl + W→Ctrl + T行指定
再起動
sudo systemctl restart mastodon-web
sudo systemctl restart mastodon-sidekiq
sudo systemctl restart mastodon-streaming
押し上げ
git add。
git commit -m ''
git push -u origin master
(ブランチのマージ)git merge ~~
文字列検索
grep -rl
ブランチ切り替え
git checkout
ブランチ更新
git fetch
git merge
git fetch上流
git mergeアップストリーム/マスター
git fetch origin master
git merge origin / master
git pull origin master-temporary
文字列検索
grep -nl
[関連](https://qiita.com/shunsakai/items/9187afbd58ffe3925f90)
ログイン
sudo su-マストドン
cd〜/ live
マスター追従
バンドルインストール
yarn install --pure-lockfile
RAILS_ENV =生産バンドルexec rails asset:precompile
RAILS_ENV =製品バンドルexec rails db:migrate
メモ
rbenv install 2.5.3←rubyの新しいバージョンをインストールする。マストドンのバージョンに合ったバージョンをインストールすること
gem install bundler←rbenv installで入れたバージョンのrubyにbunderを追加する。rbenvinstallをしたら必ず行うこと。
bundler install←マストドンのアプリケーション(サーバサイド)が使うモジュールをインストールする。gitpull(またはfetchとmerge)上流マスターをしたら必ず行うこと
yarn install←マストドンのアプリケーション(クライアントサイド)が使うモジュールをインストールする。gitpull(またはfetchとmerge)上流マスターをしたら必ず行うこと
bundle exec rails db:migrate←マストドンで使われてるDBを現在のバージョンに合わせて最適化する。gitpull(またはfetchとmerge)上流マスターをしたら必ず行うこと
bundle exec rails asset:precompile←マストドンのWebクライアントを現在のバージョンでビルドする。gitpull(またはfetchとmerge)アップストリームマスターをしたら必ず行うこと
日付 結果 原因
2019/12/8 ssh接続が出来ない ptables-persistentをデフォルト設定で導入したせいで変更したPortでssh接続ができなくなった。
接続を切る前に、再度接続可能かを確かめる
細部よりまずは動くかどうかを優先する
ファイルごとの確認じゃなくて一行ごとに変更点の確認が必要
Virtual Boxで一度鯖を立ててから、本番環境へ移行する
sshログインできなくなってもVirtual Boxからログインして設定せる
原因が分からない問題を、箇所を絞って委託する
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment