2019-12-01

開発日記 Dockerfile編 -後編- ~Cookiecutter Django調べた。~

まずは

こちらの前編の続きです。

CFFI とは
Cで実装された処理をpythonで使うためのライブラリ。
詳しくはFFIから学ぶといいかもしれません。

調べ。

libffi-dev
違う言語をコンパイルしてくれる。

py-cffi
libffi-devCとPython向けっぽいです。

gettext
他のGNUパッケージが多言語メッセージを生成するのを支援するフレームワークを提供するツールのセット
つまり翻訳してくれる感じみたい。

postgresql-client
psqlクライアント
postgresqlに接続するために必要。

COPY ./requirements /requirements
requirementsフォルダをコンテナ側にファイル・ディレクトリをコピーする。

RUN pip install -r /requirements/local.txt
ビルドする際にlocal.txtに記載されたライブラリをインストールする。

COPY ./compose/production/django/entrypoint /entrypoint
entrypointファイルをコンテナ側にファイル・ディレクトリをコピーする。

RUN sed
sedはLinuxユーティリティ。
文字列を編集する。

-i 's/\r$//gr' /entrypoint
entrypointフォルダ内を
-iで直接編集する。
あとは正規表現。

chmod +x
で権限を実行。

chown
djangoフォルダ所有者を指定。

COPY ./compose/production/django/start /start RUN sed -i 's/\r$//g' /start RUN chmod +x /start RUN chown django /start
は上記と同じ。

COPY . /app
は全体をコピーしています。

RUN chown -R django /app
所有権を再帰的に変更。

USER django
コンテナユーザー。
ちなみに所有権や権限などはこのユーザーとなります。

WORKDIR /app
コンテナ作業ディレクトリの指定。

ENTRYPOINT ["/entrypoint"]
コンテナをファイルとして使用する場合に定義するコマンド。

調べたもの

Alpine Linux packages

2019-12-01

開発日記 Dockerfile編 -前編- ~Cookiecutter Django調べた。~

Cookiecutter Django

Cookiecutter Djangoは
ひとことで言うとdjangoに必要なファイルを一括作成してくれます。
gitはこちら↓
GitHub - pydanny/cookiecutter-django: Cookiecutter Django is a framework for jumpstarting production-ready Django projects quickly. 今回はそこで作成されるcompose/local/django/Dockerfile
を調べていきたいと思います。

Dockerfile

FROM python:3.7-alpine

ENV PYTHONUNBUFFERED 1

RUN apk update \
  # psycopg2 dependencies
  && apk add --virtual build-deps gcc python3-dev musl-dev \
  && apk add postgresql-dev \
  # Pillow dependencies
  && apk add jpeg-dev zlib-dev freetype-dev lcms2-dev openjpeg-dev tiff-dev tk-dev tcl-dev \
  # CFFI dependencies
  && apk add libffi-dev py-cffi \
  # Translations dependencies
  && apk add gettext \
  # https://docs.djangoproject.com/en/dev/ref/django-admin/#dbshell
  && apk add postgresql-client

# Requirements are installed here to ensure they will be cached.
COPY ./requirements /requirements
RUN pip install -r /requirements/local.txt

COPY ./compose/production/django/entrypoint /entrypoint
RUN sed -i 's/\r$//g' /entrypoint
RUN chmod +x /entrypoint

COPY ./compose/local/django/start /start
RUN sed -i 's/\r$//g' /start
RUN chmod +x /start

WORKDIR /app

ENTRYPOINT ["/entrypoint"]

FROM python:3.7-alpine
はpythonをalpineベースで使う場合の記述。

ENV PYTHONUNBUFFERED 1
はpythonのバッファリングをオフにする環境変数。

RUN apk update \
はalpineでのアップデートコマンド。

apk add
はalpineでのインストールコマンド。

--virtual
は--virtualを指定して仮の名前をつけてパッケージをインストールすると、
後で必要のなくなったパッケージを削除できる。

build-deps
はなんか必要らしいです。
docker - What is .build-deps for apk add --virtual command? - Stack Overflow

gcc
プログラミング言語のコンパイラをまとめたもの。

python3-dev
はpython開発ツール。
モジュールを構築したりする。

musl-dev
Cライブラリで何かを最適化するらしいです。

postgresql-dev
dockerでpostgresqlを使う時に必要。

jpeg-dev
画像ファイルのjpeg形式を使えるようにしている。

zlib-dev
データ圧縮ライブラリ。

freetype-dev
フォントをレンダリングするライブラリ。

lcms2-dev
JPEG の圧縮や展開を高速化をする。

openjpeg-dev
JPEG 2000コーデック(データのエンコード（符号化）とデコード（復号）を双方向にできるソフト)

tiff-dev
画像データのTag Image File Format（TIFF）をサポートする

tk-dev
Motifのルックアンドフィールを提供するクロスプラットフォームのグラフィカルツールキット

tcl-dev
クロスプラットフォームで解釈されるスクリプト言語

参照元

Alpine Linux packages

Debian -- Debian パッケージ検索

2019-12-01

Docker Dockerfileインストラクション編 ~最低限の知識~

Dockerfile内で使用するインストラクション

FROM
ビルドするイメージのベースイメージ

RUN
イメージをビルドする際にコンテナで実行するコマンドを定義

COPY
ホスト側からコンテナ側にファイル・ディレクトリをコピー

ADD
COPYの機能に加えてアーカイブの自動展開やURLを指定して
ファイル・ディレクトリをコンテに追加。
OSのベースイメージ作成時のような特殊はケースで活用される

CMD
コンテナがフォアグラウンドで実行するコマンドを定義。

ENTRYPOINT
コンテナを実行可能ファイルとして使用する際に定義するコマンド。
CMDとENTRYPOINTは併用可能。

ARG
docker image build時に利用する変数。

ENV
コンテン内の環境変数を定義。

EXPOSE
コンテナが公開するポート。

VOLUME
ホストや他のコンテンからマウントできるポイントを作成する。

LABEL
イメージに追加するメタデータ。

STOPSIGNAL
コンテナに送られて終了するシステムコール信号を設定。

HEALTHCHECK
コンテナ内でコマンドを実行し、その結果をヘルスチェックとして利用する。

USER
コンテナ実行時のコンテナユーザー。イメージビルド時、USER定義後のRUNもそのユーザーで実行される。

WORKDIR
コンテナの作業ディレクトリ。

ONBUILD
コンテナ内で実行するコマンドを定義するが、定義したイメージでは実行されない。
ONBUILDを定義したベースイメージを利用するイメージのビルド時に実行される。

2019-12-01

Linux alpineLinux編 ~最高スピード！~

Linux

alpineLinuxとは

今回はdocker imageを作成する際に
Linuxディストリビューションを選択する案として有力なalpineについて書きます。

特徴
alpineLinux(アルパインリナックス)
musl libc , BusyBoxを基に構成。
軽量でセキュアなLinux。
組込み系にも使われている。

とにかく軽い！

比較 docker image
ubuntu 64.2MB
alpine 5.55MB
centos 220MB

メリット
docker pull push などの時間が短縮されるなどのメリットが！

使い方

パッケージマネージャー apk
ちなみにubuntuではapt-get
centosではyumなので注意！

インストール　

apk add

インストール済みパッケージの確認

apk info

パッケージのアップデート

apk update

パッケージの検索

apk search

パッケージの削除

apk del

注意点
bashがデフォルトでないのでashを使うようにしましょう。
docker run -it alpine /bin/bash
↓↓
docker run -it alpine /bin/ash
ちなみにbashもインストールすれば使えます！

2019-11-28

postgresql インストール編 ~macで使えるようにする~

postgresql

前提

homebrewがインストールされていて
brewコマンドが使えること。
またパッケージ版をインストールしている方は
起動時にデフォルトのport番号がぶつかるので注意。

インストール

Homebrewのアップデート

brew update

postgresqlインストール

brew install postgresql

バージョン確認

psql -V

インストール位置確認

which psql

※複数のサイトに以下のデータベース初期化のコマンドが記載されていますが、
インストール時に実行されているため行なっていません。

initdb /usr/local/var/postgres -E utf8

起動・停止

起動

brew services start postgresql

確認

brew services list

停止

brew services stop postgresql

データベース表示

起動後確認できます。

psql -l

アンインストール

全てのバージョンのpostgresqlをアンインストール

 brew uninstall --force postgresql

initdb で指定したファイルを削除。
削除しない場合は再インストールした場合にエラーが起こると思います。

ls -l /usr/local/var/postgres

rm -rf /usr/local/var/postgres

2019-11-28

開発日記 postgres編 ~コマンド忘れないように~

postgresql

コマンドメモメモ

まずpostgresqlがパッケージ版とbrewの2つインストールされていないか注意。

以下brew版です。

postgresqlを起動する

brew services start postgresql

postgresqlを停止する

brew services stop postgresql

起動しているか確認する。

brew services list

postgresqlのバージョンを確認する。

psql --version

dockerでpostgresqlを起動後実行する。

docker exec -it [containerID or containerName] psql -U postgres

2019-11-20

django 認証方式編 ~セキュリティ~

Django

drfの認証方式

1.Basic認証
(rest_framework.authenticaton.BasicAuthentication)
2.Cookie認証
(rest_framework.SessionAuthentication)
3.トークン認証
(rest_framework.authentication.TokenAuthentication)
4.リモートユーザー認証
(rest_framework.authentication.RemoteUserAuthentication)
5.JWT認証
(サードパーティを使用する)

Basic認証

ユーザー名やパスワードなどをBase64 エンコードして、
そのトークンをリクエストのヘッダーに毎回書き込んで送信する。
ただ複合ができるのでセキュリティ的にWebアプリケーションにはというより検証に使う。

Cookie認証

サーバー側のセッションに情報を保存。
そのセッションを特定するためのIDをWebブラウザ側のCookieに保存して
リクエストヘッダにセッションIDをセットして送信することでサーバー側で判別する。
つまりサーバ側のセッションが管理している。
比較的簡単に導入できてDjangoAdminの管理サイトでも同じ方式。

トークン認証

DBにユーザーに1対1で紐付くトークンを発行して保存する。
ただ永続的にトークンが残るためセキュリティ的に少し問題がある。
そこでJWTでは有効期限が設定できる。

リモートユーザー認証

Webサーバに認証を委譲す、その結果として環境変数「REMOTE_USER」が設定していれば
認証をされているという認証方式。

JWT認証

認証情報を含んだJSON形式のデータをHTTPヘッダで送信できるように
エンコードしたトークンで署名を含んでいるために改ざんが検知できる。
トークン自体に認証情報が含まれているためユーザを特定することができる。
またDBも必要がない。
トークンに有効期限も設定することも可能。
注意点は元の情報を復号できるためパスワードなどの機密情報は含めない。