Docker compose まとめ
わかりやすい
docker-composeとdockerの違いについて
docker-composeとは複数の環境をまとめて作るときに使う
マイクロサービス という事
docker-compose.yml ファイルに記載する
記載例
//version: 3と記載するのがポイント
version: '3'
services:
web:
build: .
ports:
- "5000:5000"
volumes:
- .:/code
- logvolume01:/var/log
links:
- redis
//redis(NoSQL)のDBと一緒に利用することがわかる
redis:
image: redis
volumes:
logvolume01: {}
もし docker-comoseで記載しないと、 docker run で２つ起動して上げれば良い
これは WordPress の例
docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:5.7 docker run --name some-wordpress -e WORDPRESS_DB_PASSWORD=my-secret-pw --link some-mysql:mysql -d -p 8080:80 wordpress
docker runはこのように書く option と イメージ を指定する必要がある。
docker run [OPTIONS] IMAGE [COMMAND] [ARG...]
imageの一覧は
docker images
REPOSITORY TAG IMAGE ID CREATED SIZE python latest efdecc2e377a 2 weeks ago 933MB mariadb latest 1f9cfa8dc305 3 weeks ago 356MB voting-app latest f8d9398120d6 2 months ago 74.7MB <none> <none> fde4aa84a5d5 2 months ago 951MB redis latest dcf9ec9265e0 2 months ago 98.2MB
ということは mariadbをrunしたいときは
--name はイメージに自分の名前をつけた わかり易い名前が推奨されている
docker run --name my_mariadb mariadb
しかしエラー
You need to specify one of MYSQL_ROOT_PASSWORD, MYSQL_ALLOW_EMPTY_PASSWORD and MYSQL_RANDOM_ROOT_PASSWORD
パスワードをセットしなさいと言われる
docker run --name my_mariadb mariadb -e MYSQL_ROOT_PASSWORD=xxxxxx -d mariadb:3.1
しかしエラー 同じ名前のコンテナがあるよ。削除するかリネームしなさいと言われる Conflict. The container name "/my_mariadb" is already in use by container "36d38d69c7a7bf803a27916aca45f458d531e1a4a14770416343df330ff295c8". You have to remove (or rename) that container to be able to reuse that name.
コンテナ削除する まずはdockerのコンテナの確認
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 36d38d69c7a7 mariadb "docker-entrypoint.s…" 12 minutes ago Exited (1) 12 minutes ago my_mariadb 3b70100d7faa python:3.7.3 "/bin/bash" 29 hours ago Exited (127) 29 hours ago suspicious_cerf 298c4e99003e python:3.7.3 "python3" 29 hours ago Exited (0) 29 hours ago objective_golick 1ad46aeb98e1 34a "python3" 29 hours ago Exited (0) 29 hours ago strange_haslett e61049880c06 python:3.7.3 "/bin/bash" 30 hours ago Exited (0) 29 hours ago optimistic_brown 52051b32155e python "-i -t python:3.7.3 …" 30 hours ago Created
このID 36d.....を削除したい
docker rm 36d
これでなくなったので再度挑戦
エラー 基本に戻り dockerの本のチュートリアルをする
dockerを起動 名前はwebserver デーモンで ポートはホストが80 コンテナのポートは80 webserber はeNginX $ docker run --name webserver -d -p 80:80 nginx
エラー docker: Error response from daemon: Ports are not available: listen tcp 0.0.0.0:80: bind: address already in use.
調べてみると -p オプションの左側がホストのポート 右側がコンテナのポート(ローカルPCで接続するところ)らしい
でもって、Nginxのコンテナ側のポートを変更する。
エラー コンテナのwebserverという名前は使われているらしい docker: Error response from daemon: Conflict. The container name "/webserver" is already in use by container "08cb6a6c8097d57d955fa664d7e979efd6ce1f72507888e4131fdfd99520121b". You have to remove (or rename) that container to be able to reuse that name.
確認してみる コンテナはps -a で確認できる
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 08cb6a6c8097 nginx "nginx -g 'daemon of…" 10 minutes ago Created webserver 8f01129608e1 mariadb "docker-entrypoint.s…" 32 minutes ago Exited (1) 32 minutes ago my_mariadb 3b70100d7faa python:3.7.3
あった、ということは container runは一発でコマンドを決めないと行けないらしい buildはしなくてよいのか？という疑問がのこる また run と container runの違いは？
調べたら同じだった。
dockerのバージョンによって、同じものになったようだ
現在では docker run を利用する
公式サイトの日本語訳ドキュメント
このあたりが難しいところ 削除して// id は 08c
$ docker rm 08c
これで成功
$ docker run --name webserver -d -p 8080:8080 nginx
プロセスが動いているか確認 -d でデーモンオプションをつけたので、動いているので、確認できるはず
$ docker ps
動いていた!
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 6108bcbd3f4a nginx "nginx -g 'daemon of…" 28 seconds ago Up 27 seconds 80/tcp, 0.0.0.0:8080->8080/tcp webserver
docker stats
詳細を確認 statsと打たないといけない
$ docker stats webserver
stats — Docker-docs-ja 19.03 ドキュメント
CTR + C で抜けれる
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS 6108bcbd3f4a webserver 0.00% 1.93MiB / 1.943GiB 0.10% 1.05kB / 0B 8.19kB / 0B 2
プロセスの停止
docker stop webserver
コンテナを再度削除して作り直す 成功！
$ docker run --name webserver -d -p 80:80 nginx
localhost:80でnginxが表示される
原因はMAMPが動いていたから
詳細はinspectで確認できる mariadbのバージョンが知りたかったので助かった。
docker image inspect mariadb
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"GOSU_VERSION=1.10",
"GPG_KEYS=177F4010FE56CA3336300305F1656F24C74CD1D8",
"MARIADB_MAJOR=10.4",
WordPress nav 縦並び
こうしたい
でもWordPressが出力するnavにはいろんなクラスが当てられる それがuser-agentという、ブラウザのデフォルト値に関係してしまうので、 CSSがうまく当たらない
WordPressにはこれだけ
<div class="nav-menu">
<div class="nav-sns">
<a class="sns-link fa" href=""></a>
</div>
<?php wp_nav_menu(); ?>
</div>
でHTMLを確認すると、いろんなクラスが出力されている
それに対してすべてCSSを当てていく
desiplay: flexで対応
もともとは
display: list-itemがあたっていた
@media screen and (max-width:600px) {
.nav-menu {
display: flex;
width: 70%;
height: 600%;
background-color: #F49F0D;
top: 78px;
right: 0;
opacity: 0.9;
}
.menu-main-container ul {
display: flex;
flex-direction: column;
}
.menu-main-container ul li {
text-align: left;
width: 100%;
display: flex;
flex-direction: column;
z-index: 999;
}
}
Swift リファクタリング忘備録 注意-読む価値はありません。!
デリゲート処理はweakで宣言しておかないと、メモリーリークを起こす可能性がある。
//変更前 protocol CommentDelegate { func commentOptionTapped(comment: Comment) } private var delegate: CommentDelegate //変更後 protocol CommentDelegate: class { func commentOptionTapped(comment: Comment) } private weak var delegate: CommentDelegate
ポイント protocol はclass属性
アクセスするプロパティは weak で宣言
SWIFT awakeFromNib とinitWithCoderの違い 忘備録
initWithNibName：bundleとは
initWithNibName：bundle：はNSおよびUIViewControllerのメソッドです（CocoaではNSWindowController）。 nibは、実際には、-window（NSWindowController）または-loadView（NS / UIViewController）に応答して後でロードされます。 これは遅延読み込みです。 コントローラのウィンドウまたはビューが必要ない場合、そのnib先は読み込まれず、時間を節約できます。 View Controllerをインスタンス化するときにinitWithNibName：bundle：を送信するだけでよく、View-Controllerサブクラスでカスタムのインスタンス化動作を実装するときにのみオーバーライドする必要があります。 サブクラスがmyViewControllerやinitを定義してinitWithNibName：bundle：をハードコードされた値で送信するなどの便利なコンストラクターのみを追加する場合は、initWithNibName：bundle：もオーバーライドする必要はありません。
initWithCoder
initWithCoder：は、アーカイブをアーカイブ解除するためにアーカイブからアーカイブ解除されたすべてのオブジェクトに送信されるメッセージです。オブジェクトは、アーカイブからすべてのivar値とプロパティ値を読み込むことにより、このメッセージに応答します。
nib先はアーカイブなので、initWithCoder：はnib先のすべての実際のオブジェクトに送信されます。そのような場合、通常、nib先から何も抽出する必要はありません。 Appleの実装は、通常のものをすべて処理します。アーカイブから最初に配置するカスタムプロパティ（encodeWithCoder：内）のみを抽出する必要があるため、カスタムプロパティをnibでエンコードできないため、nibsからデコードする必要はありません。 。
「File's Owner」、「First Responder」、およびその他の特定のオブジェクトは偽のオブジェクトであることに注意してください。それらは実際にはnib先には存在しません。 Xcodeのnibエディターは、これらを負のID番号で表示します。
通常、initWithCoder：をオーバーライドする必要はありません。そうするときは、オブジェクトがどのようにインスタンス化されたか（コードまたはnibからアーカイブ解除された）に関係なく、最初から特定のプロパティ（可変配列またはセットなど）を埋める必要があるオブジェクトがある場合です。
initWithCoder：と1つ以上の非デコード対応物の両方を定義すると、それらの間にコードのリスクが高くなります。通常、commonInitメソッドを定義し、そこに通常のものを配置し、両方のinit [WithCoder：]メソッドに[self commonInit]を送信させます（注：スーパーではありません！）。
awakeFromNib
awakeFromNibは、nib内のすべてのオブジェクトが完全にロードされた後にnib内のすべてのオブジェクトに送信されるメッセージであり、そのnib内のすべてのアウトレット接続を再接続します。
いくつかの注意事項があります： これは、すべてのアウトレットが満たされることを意味するものではありません。オブジェクトをロードしたnib先で接続しないものは、そのロードで満たされません。これらのivar / propertiesは空のままです。オブジェクトが別のnib先のファイルの所有者である場合、そのnib先に設定されているアウトレット接続を完了するために、そのnib先をロードする必要があります。同じことは、同じFile's Ownerで2つ以上のnib先をロードする場合にも当てはまります。 2つの別々のnib先でオブジェクトを作成することはできません。両方のnib先をロードすると、2つのオブジェクトが生成されます。 （シングルトンの場合は、キャットファイトが予想されます。） 特定のアウトレットが接続されているnib先からオブジェクトをロードし、それがファイルの所有者であり、同じアウトレットが他の何かに接続されている別のnib先をロードすると、新しい接続が最初の接続をオーバーライドします。同じことは、同じFile's Ownerで2つ以上のnib先をロードする場合にも当てはまります。 Cocoa Touchでは、これは冗長であり、混乱を招く可能性があります（「私のアウトレットが[最初のnib先のオブジェクト]に接続されていないのはなぜですか？」） Cocoaでは、最初のオブジェクトは必ずしも解放されないため、リークが発生する可能性があります。 （Cocoa TouchはKVCを使用してアウトレット接続を埋めますが、Cocoaは使用しませんが、アクセサーを定義する場合はアクセサーを使用します。） Cocoaでは、awakeFromNibはnib内のすべてのオブジェクトとFile's Ownerに送信されます。 Cocoa Touchでは、ファイルの所有者には送信されません。
参照元
Visual Studio Code 文字列置換 正規表現検索
目的:data-layer属性がたくさんあったので一度で置換したい。
もとの文字列
data-layer="xxx_xxxx_xxxx" class=
これを下記に置き換える
class=
. は任意の1文字
+ 直前の1回以上の繰り返し
Command + F
矢印をクリックし、ボタンを押す
Django 便利なリファレンス集 ver2.2.0途中 読まないこと
モデルの関連について
Model field reference | Django documentation | Django
モデルの型
ImageField imageを格納するとき
IntegerField Int型
CharField 文字列
https://docs.djangoproject.com/en/2.2/ref/models/fields/#imagefield
Djangoアプリ Heroku デプロイ
初めからの手順
git のインストール
Heroku CLIのインストール
herokuにログインしたり、デプロイするためのコマンドを利用できる devcenter.heroku.com
djangoをherokuにデプロイするには以下の３つが必要
runtime.txt => Pythonのバージョンを記載
requirements.txt
setup.py
Pipfile
runtimte.txt
python-3.6.0
必要なモジュールのインストール
python3 -m pip install gunicorn
gunicornとは何かというとWSGI HTTPサーバーのこと
Gunicornの「Green Unicorn」は、UNIX用のPython WSGI HTTPサーバーです。 これは、RubyのUnicornプロジェクトから移植されたpre-forkワーカーモデルです。 Gunicornサーバーは、さまざまなWebフレームワークと幅広く互換性があり、シンプルに実装され、サーバーリソースの使用量が少なく、かなり高速です。
requirements.txt ファイルの作成 herokuこのファイルを見て、モジュールインストールする
pip freeze でインストールされているパッケージが表示される。それをそのまま記載する。
pip freeze //=== asgiref==3.2.7 Django==3.0.6 gunicorn==20.0.4 Pillow==7.1.2 pytz==2020.1 sqlparse==0.3.1
で表示されたものをrequirement.txtに記載する
Prockfile の作成
どのWEBサーバーを利用するか、どんなコマンドを実行するか記載してあげる
web: gunicorn "プロジェクト名".wsgi --log-file - release: python manage.py migrate
==========今日はここまで
pip install whitenoise
.gitignore ファイルの作成
不要なログ・ファイルなどをuploadしないため コピペして.gitignoreファイルに貼り付ける
//MACの場合追記する .DS_Store
git init git add . git status //チェックする git commit -m "initial"
heroku
heroku create xxxxapp_name //これでdeployできる git push heroku master
デプロイにはSTATIC_ROOTの定義が必要
setting.py
STATIC_URL = '/static/' //アプリ内のフォルダ名 STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles')
修正したら git push heroku master を繰り返す
logの見方
//logを見れば問題がわかる heroku logs --tail
Procfile ファイルの作成
拡張子はつけない プロセスを記載する。
//webはプロセス名 //gunicornはコマンド //xxxdjango_projectはsetting.pyに登録してるアプリ名 //wsgi Web Service Gateway Interface web: gunicorn xxxxdjango_project_name.wsgi //他のバックグラウンドのワーカーなども登録可能
ALLOWED_HOSTの追加
Djangoのセキュリティーの為
セキュリティーキーの作成 python3.6以上が必要
operation error no such table: xxx_xxx
herokuにDBがないと言われている
heroku上のDBの確認
//pg はポストグレスの略 herokuではDBはポストグレス heroku pg
db上の設定をしてくれるライブラリ
インストールするだけで whitenoiseやDB-urlなどを設定してくれる
pip install django-heroku
setting.py
import django_heroku
