- 投稿日：2020-10-19T23:11:11+09:00
Djangoチュートリアル（ブログアプリ作成）⑤ - 記事作成機能編
前回、Djangoチュートリアル（ブログアプリ作成）④ - ユニットテスト編 ではユニットテストの実装方法を学んでいきました。
本来であれば、せっかくなので期待するテストを先に書くテスト駆動開発スタイルで実装していきたいところですが
このチュートリアルでは Django ではどんなことが出来るかを学びながらなので、先に実装してからユニットテストを書いていきます。これから、何回かに分けて今回は以下の機能を追加していきます。
1.記事の作成 (Create)
2.記事の詳細 (Read)
3.記事の編集 (Update)
4.記事の削除 (Delete)これら機能の頭文字をとって「CRUD」とここでは呼ぶことにします。
(厳密にいえば既に blog_list で Read は出来るので違うかもしれませんが）さて、今回はベースともいえる記事の作成機能を追加していきましょう。
これまでは管理サイトを使って superuser 権限で記事を追加していましたが、アプリ内で記事を作成出来たほうが便利ですよね。form の準備
アプリからデータを追加するときは form という仕組みを使います。
form がユーザから入力データを受け付け、view を通して model へデータを渡してデータベースへ登録することができるようになります。まずは blog アプリ配下に forms.py というファイルを作成します。
. ├── blog │ ├── __init__.py │ ├── admin.py │ ├── apps.py │ ├── forms.py # 追加 │ ├── migrations │ │ ├── 0001_initial.py │ │ └── __init__.py │ ├── models.py │ ├── tests │ │ ├── __init__.py │ │ ├── test_forms.py │ │ ├── test_models.py │ │ ├── test_urls.py │ │ └── test_views.py │ ├── urls.py │ └── views.py ├── db.sqlite3 ├── manage.py ├── mysite │ ├── __init__.py │ ├── settings.py │ ├── urls.py │ └── wsgi.py └── templates └── blog ├── index.html └── post_list.html作成した forms.py の中身はこのようになります。
forms.pyfrom django import forms from .models import Post class PostCreateForm(forms.ModelForm): # DjangoのModelFormでは強力なValidationを使える class Meta: model = Post # Post モデルと接続し、Post モデルの内容に応じてformを作ってくれる fields = ('title', 'text') # 入力するカラムを指定説明文も入れているのである程度わかるかと思います。
データを投入したい model を指定すると form が対応する入力フォームを用意してくれるようになります。なお、最終行でデータを入力するカラムをフィールドとして指定していますが、
fields = 'all' と定義することで全てのカラムを手入力するように指定することもできます。urls.py の修正
新たに view に追加するクラスは **PostCreateView と名前を予め決めておき、
urls.py では次のようにルーティングを追加しておきましょう。urls.pyfrom django.urls import path from . import views app_name = 'blog' urlpatterns = [ path('', views.IndexView.as_view(), name='index'), path('post_list', views.PostListView.as_view(), name='post_list'), path('post_create', views.PostCreateView.as_view(), name='post_create'), # 追加 ]success_url では、データベースの変更に成功した場合にリダイレクトさせるページを指定しています。
「アプリ名：逆引きURL名」の形で指定し、結果的に urls.py で指定した 'post_list' にリダイレクトされることになります。
※reverse_lazy は、view に対応した「URLの文字列」を返す。今回であれば /blog/post_list を返してくれますviews.py の修正
先ほど追加するクラス名は PostCreateView と決めましたね。
また、form で入力フォーム用のクラスも作成しました。次は views.py の中で、またまた汎用クラスビューを使ってクラスを作成します。
views.pyfrom django.views import generic from django.urls import reverse_lazy from .forms import PostCreateForm # forms.py で作ったクラスをimport from .models import Post class IndexView(generic.TemplateView): template_name = 'blog/index.html' class PostListView(generic.ListView): model = Post class PostCreateView(generic.CreateView): # 追加 model = Post # 作成したい model を指定 form_class = PostCreateForm # 作成した form クラスを指定 success_url = reverse_lazy('blog:post_list') # 記事作成に成功した時のリダイレクト先を指定Django の強力なクラスベース汎用ビューのおかげで、これだけのコードで済みます。
作成したい model、作成した form クラス、そして記事作成が成功した時のリダイレクト先を指定してあげるだけです。template の準備
まだ記事作成（投稿）用の html は作成していなかったので、templates/blog 配下に作成してあげましょう。
名前は post_form.html とします。
※クラスベース汎用ビューの命名規則に沿うことで template 名を指定しなくても OK になります└── templates └── blog ├── index.html ├── post_form.html # 追加 └── post_list.htmlpost_create.html<form action="" method="POST"> <table class="table"> <tr> <th>タイトル</th> <td>{{ form.title }}</td> </tr> <tr> <th>本文</th> <td>{{ form.text }}</td> </tr> </table> <button type="submit" class="btn btn-primary">送信</button> {% csrf_token %} </form>forms.py の fields で指定した入力フィールドを form という変数で受け取ることができるので、
template 側では form.title と form.text という形で取り出すことができます。また CSRF (クロスサイトリクエストフォージェリ) という、入力フォームを利用した攻撃を防ぐためのものです。
入力フォームを html に表示させる時は、必ず入れておきましょう。この状態で runserver コマンドでサーバを起動すると、見た目はひどいものですが入力フォームが表示されます。
（度々ですが、まずは Django の基本をおさえてから見た目を整えます）
では試しに値を入力し、送信してみましょう。
送信を押すと、post_list にリダイレクトされます。
そして、先ほど投稿した記事が追加されていることが分かるかと思います。
これで無事に記事投稿機能を追加することができました。
test_views.py の修正
最後に今回の機能のテストを実装しましょう。
test_views.py に下記のテストクラスを作成します。
test_views.py... class PostCreateTests(TestCase): """PostCreateビューのテストクラス.""" def test_get(self): """GET メソッドでアクセスしてステータスコード200を返されることを確認""" response = self.client.get(reverse('blog:post_create')) self.assertEqual(response.status_code, 200) def test_post_with_data(self): """適当なデータで POST すると、成功してリダイレクトされることを確認""" data = { 'title': 'test_title', 'text': 'test_text', } response = self.client.post(reverse('blog:post_create'), data=data) self.assertEqual(response.status_code, 302) def test_post_null(self): """空のデータで POST を行うとリダイレクトも無く 200 だけ返されることを確認""" data = {} response = self.client.post(reverse('blog:post_create'), data=data) self.assertEqual(response.status_code, 200)基本となる GET の確認、適当なデータの投入とリダイレクトの確認、そして空データ投入時のレスポンスを見ています。
最後にテストを実行しましょう。
無事に通りましたね。
次回は一気に記事の詳細画面を作成していきます。
- 投稿日：2020-10-19T19:43:16+09:00
Docker 開発環境のパフォーマンスを上げる
やりたいこと
Docker コンテナ環境 (特に VSCode Remote Containers) を快適に動かす
方法
DockerでVolumeをマウントするとき一部を除外する方法 を使って、ビルドファイル等(.gitignore に書くような場所)のボリュームマウントを外す。
経緯
VSCode の Remote Container を使ってコードのビルドを行うと動作が重くなったり、突如 Docker ホストが落ち たり、というということが発生して、最初は何が原因なのか検討もつかなかった。
マウントファイルの高負荷が原因と疑って実施してみたところ、解決、パフォーマンスも改善した。Remote Containers を 使う場合は開発時にマウントさせる必要もあまりないと思うので、 cached のオプションを使うよりも効果が高そう。
サンプル
この方法を使っているサンプルリポジトリ
- https://github.com/tktcorporation/youtube_to_m3u8参考
- https://qiita.com/suin/items/e53eee56da23d476addc
- https://www.366service.com/jp/qa/8bc9e2acccd4309e504a8c3877c6fe2a
さいごに
Remote Conyainers すてき！
- 投稿日：2020-10-19T19:31:01+09:00
【docker】シリアルポートからデータを読む (u-blox 受信機)
docker container でシリアルポートからのデータを扱いたい
Jetson NanoでUSBでu-blox 受信機を接続して、docker container でデータを読むことができました。
そのときのメモです。多分、Jetson Nanoや u-blox は関係なく、一般的な初歩的なお話だと思います。(^^;)
復習も兼ねて「くどく」書いています。。。ポイントは、Docker のマニュアルにもありますが、ホスト側のシリアリポートをそのまま仮想環境にマッピングするには、一言、docker run の引数に書くだけでOKです。
docker run --device=<ホストOSのdevice>:仮想環境のdevice>とするだけです。実際は、Docker-docs-ja で
等を読むと、権限や通信帯域の設定など、細かい話もあるにはあります。が、今回はホストOSと同じ設定（どちらもubuntu18.04だし）なのでdon't care でOKでした。
動作確認
以下、Jetson Nanoでu-blox M8TをUSBで接続し、最後に
docker runで入力を読めることを確認したときのメモです。シリアル通信するデバイスの動作確認
デバイスはu-blox M8Tを使いました。（だから何だ。。。）
$lsusb Bus 001 Device 004: ID 1546:01a8 U-Blox AG Bus 001 Device 002: ID 0bda:5411 Realtek Semiconductor Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub $dmesg ... [1442054.399797] tegra-xusb-padctl 7009f000.xusb_padctl: power on UTMI pads 1 [1442054.403431] tegra-xusb 70090000.xusb: Firmware timestamp: 2019-10-17 15:58:59 UTC, Version: 50.25 release [1442054.404047] tegra-pmc: PMC tegra_pmc_utmi_phy_disable_sleepwalk : port 0 [1442054.404242] tegra-pmc: PMC tegra_pmc_utmi_phy_disable_sleepwalk : port 1 [1442054.404427] tegra-pmc: PMC tegra_pmc_utmi_phy_disable_sleepwalk : port 2 [1442054.405876] tegra-xusb 70090000.xusb: exiting ELPG done [1442054.409069] usb usb2: usb_suspend_both: status 0 [1442054.750106] usb 1-2.4: new full-speed USB device number 4 using tegra-xusb [1442054.773772] usb 1-2.4: New USB device found, idVendor=1546, idProduct=01a8 [1442054.773846] usb 1-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [1442054.773896] usb 1-2.4: Product: u-blox GNSS receiver [1442054.773944] usb 1-2.4: Manufacturer: u-blox AG - www.u-blox.com [1442054.864251] cdc_acm 1-2.4:1.0: ttyACM0: USB ACM device [1442054.864676] usbcore: registered new interface driver cdc_acm [1442054.864679] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters $ ls -lth /dev/ttyACM* crw-rw---- 1 root dialout 166, 0 10月 19 17:08 /dev/ttyACM0u-blox 受信機をUSBポートにさしました。
$ sudo usermod -a -G dialout $USER $ screen /dev/ttyACM0 115200screenはctrl+a d で終了します。
docker 素材の用意
次に、シリアルポートからデータを読む python スクリプトを用意します。pyserialを使います。
serial_read.py#!/usr/bin/env python3 import sys import serial port = sys.argv[1] with serial.Serial(port, 115200) as ser: while True: data =ser.read(1024) print(data)
python3 serial_read.py /dev/ttyACM0で動作確認をした後、Dockerfile を作成します。FROM ubuntu:18.04 # Install python and pip RUN apt-get update -y && \ apt-get install -y -qq --no-install-recommends \ python3 \ python3-serial \ && apt-get clean \ && rm -rf /var/lib/apt/lists/* ENV PATH /usr/local/bin/:$PATH # the port number the container should expose COPY serial_read.py /usr/local/bin RUN chmod +x /usr/local/bin/serial_read.py ENTRYPOINT [ "serial_read.py" ]動作確認
できたら、build して動かしてみます。ここでは、仮想環境でのシリアルポートを /dev/myserialport としました。
$ docker build -t test/serial . Successfully tagged test/serial:latest $ docker run --device=/dev/ttyACM0:/dev/myserialport --rm -it test/serial /dev/myserialport b'$GNRMC,093210.00,V,,,,,,,191020,,,N*61\r\n$GNVTG,,,,,,,,,N*2E\r\n$GNGGA,093210.00,,,,,0,00,99.99,,,,,,*71\r\n$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E\r\n$GNGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*2E\r\n$GPGSV,2,1,06,04,,,13,05,,,12,20,,,21,24,,,11*7B\r\n$GPGSV,2,2,06,26,,,09,29,,,21*7A\r\n$GLGSV,1,1,00*65\r\n$GNGLL,,,,,093210.00,V,N*5D\r\n$GNZDA,093210.00,19,10,2020,00,00*78\r\n$GNTXT,01,01,02,u-blox AG - www.u-blox.com*4E\r\n$GNTXT,01,01,02,HW UBX-M8030 00080000*60\r\n$GNTXT,01,01,02,EXT CORE 3.01 (111141)*39\r\n$GNTXT,01,01,02,ROM BASE 2.01 (75331)*19\r\n$GNTXT,01,01,02,FWVER=TIM 1.10*50\r\n$GNTXT,01,01,02,PROTVER=22.00*18\r\n$GNTXT,01,01,02,MOD=NEO-M8T-0*7D\r\n$GNTXT,01,01,02,FIS=0xEF4015 (100111)*58\r\n$GNTXT,01,01,02,GPS;GLO;GAL;BDS*77\r\n$GNTXT,01,01,02,SBAS;IMES;QZSS*49\r\n$GNTXT,01,01,02,GNSS OTP=GPS;GLO*37\r\n$GNTXT,01,01,02,LLC=FFFFFFFF-FFFFFFED-FFFFFFFF-FFFFFFAE-FFFFFF69*27\r\n$GNTXT,01,01,02,ANTSUPERV=AC SD PDoS SR*3E\r\n$GNTXT,01,01,02,ANTSTATUS=OK*25\r\n$GNTXT,01,01,02,PF=3FA*4C\r\n$GNRMC,093211.00,V,,,,,,,191020,,,N*60\r\n$GNVTG,,,,,,,,,N*2E\r\n$'無事に動いたのでよかった。(^^)/
まとめ
とりあえず、docker でシリアルポートを扱うことはできた。リソースの取り扱いにはオプションがあるので、将来的にはそれらを使うことになるかもしれないので、そのときはそのとき。
(2020/10/19)
- 投稿日：2020-10-19T19:19:45+09:00
Dockerのコンテナとホストとの関係の条件付け
はじめに
Dockerは多くのIT開発企業で導入されている環境構築を楽にする技術です。
Dockerで作成したコンテナはホスト（自身のPCやAWSなどのクラウド）に対して、ファイルを読み込んだり、また、ホストのサーバーからコンテナへ接続したり、というような関係を持ちます。
それらの関係の条件を指定するために、docker runにオプションを付けて、実行します。
今回はコンテナとホストとの関係の条件付けのためのオプションを紹介します。今回紹介する内容(docker runコマンドとオプション)
- コンテナからホストのファイルに接続できるようにする (docker run -v)
- ユーザーIDやグループIDの指定する (docker run -u)
- ホストのポートとコンテナのポートをつなげる (docker run -p)
- コンテナがアクセスできるCPUやメモリの上限を設定する(docker run --cpus)(docker run --memory)
コンテナからホストのファイルに接続できるようにする (docker run -v)
ホストのファイルをコンテナの中にも存在するように振舞わせることをマウントと言います。
コンテナは誰かに使ってもらったり、手軽に実行させたりできるように、サイズが小さいことが望ましいので、可能な限りコンテナ自体にファイルを設置しないようにします。
例えば、コードのファイルはホストに置いておき、コンテナからホストのコードのファイルを読み込ませるという場合、コードのファイルをコンテナにマウントさせる、と言います。docker run -it -v (ホストのパス):(コンテナのパス) (DockerImageの名前 or ID) bash 例) docker run -it -v /Desktop/sample_dir:/new_dir (DockerImageのID) bash => コンテナのnew_dirというディレクトリにホストのDesktopに存在するsample_dirというディレクトリがマウントされます。 (コンテナにnew_dirというディレクトリが存在しない場合は、コンテナにnew_dirというディレクトリが自動で作成されます。)ユーザーIDやグループIDの指定する (docker run -u)
ホストのファイルをコンテナでマウントさせる場合、ユーザーIDやグループIDを指定しないと、コンテナがルート権限を持ってアクセスすることができてしまいます。
ルート権限がコンテナ側にあると、コンテナからホストのファイルを作成したり、編集したり、様々なことができてしまいます。
ルート権限を持たせたくない場合には、ユーザーIDやグループIDを指定して、マウントさせます。docker run -it -u (ユーザーID):(グループID) 例) docker run -it -u $(id -u):$(id -g) -v /Desktop/sample_dir:/new_dir (DockerImageのID) bash => ユーザーIDとグループIDが指定して、ホストのファイルをマウントしたコンテナが作成される。ホストのポートとコンテナのポートをつなげる (docker run -p)
ポートとはサーバーの中の特定の場所です。
例えば、サーバーに複数のサービスがあった場合、IPアドレスだけではどのサービスに接続するか分からないため、ポートを指定します。
作成したコンテナを一つのWebサービスとする場合、コンテナのポートとホストのポートをつなげる必要があります。docker run -it -p (ホストのポート):(コンテナのポート) 例) docker run -it -p ３０００:3000 rails bash => railsというDockerImageからコンテナが作成され、railsのデフォルトのポート3000に繋がるため、ホスト側でlocalhost:3000にアクセスするとrailsにアクセスすることができます。コンテナがアクセスできるCPUやメモリの上限を設定する(docker run --cpus)(docker run --memory)
コンテナが動く時、ホストのCPUやメモリを使います。
例えば、一つのコンテナが限界までCPUやメモリを使ってしまった場合、メモリが枯渇してシステム全体が落ちてしまう可能性があります。
そのようなリスクを避けるために、それぞれのコンテナに対して、CPUやメモリの上限設定をします。docker run -it --cpus (論理コア数) --memory (メモリ容量) 例) docker run -it --cpus 4 --memory 2g ubuntu bash => ubuntuというDockerImageからコンテナが作成され、このコンテナが使えるCPUの論理コアの上限は4つで、メモリの上限は2ギガとなります。 （コンテナのCPUやメモリを確認したい時は、"docker inspect (コンテナID)"を入力します。）※自身のPCのCPUやメモリが知りたい場合はターミナルに以下の入力をすると確認できます。
- sysctl -n hw.logicalcpu_max => CPU（論理コア数）
- sysctl hw.memsize => メモリ(byte)
参考
Udemy
かめれおん講師 「米国AI開発者がゼロから教えるDocker講座」
有料ですが、初学者の私にも非常に理解しやすかったです。
最後に
本投稿が初学者の復習の一助となればと幸いです。
- 投稿日：2020-10-19T19:04:46+09:00
【Docker】Unsupported config option for services.app: 'node'
docker環境構築を作っていて、npmを初期化するコマンドを入力したら、Errorが発生した。
#docker-compose run --rm node npm init ERROR: The Compose file './../docker-compose.yml' is invalid because: Unsupported config option for services.app: 'node'このError内容を見ると、docker-compose.ymlファイルの 'node' 辺りでErrorが発生しているみたい。。。
ymlファイルの該当箇所を確認したところ、本来は「services->node」が正しいが、「services->app->node」にインデントがずれていた。。。
間違い↓
version: '3' services: app: image: nginx:latest container_name: "app" ports: - "8080:80" volumes: - ./src/html:/app - ./docker/nginx/default.conf:/etc/nginx/conf.d/default.conf node: image: node:10 container_name: node tty: true working_dir: /usr/src/app volumes: - ./src:/usr/src/app正しい↓
version: '3' services: app: image: nginx:latest container_name: "app" ports: - "8080:80" volumes: - ./src/html:/app - ./docker/nginx/default.conf:/etc/nginx/conf.d/default.conf node: image: node:10 container_name: node tty: true working_dir: /usr/src/app volumes: - ./src:/usr/src/app修正されたコードを実行したら
#docker-compose run --rm node npm init Creating network "app_default" with the default driver Pulling node (node:10)... 10: Pulling from library/node 0400ac8f7460: Pull complete fa8559aa5ebb: Pull complete da32bfbbc3ba: Pull complete e1dc6725529d: Pull complete 572866ab72a6: Pull complete 63ee7d0b743d: Pull complete 90a199058c87: Pull complete eec01b4217d9: Pull complete a6a01f1bcd7b: Pull complete Digest: sha256:9d06418fa4335f9cf96c59d5c09372f7a56329e7234456ee9fe2340c4ac35a95 Status: Downloaded newer image for node:10 Creating app_node_run ... done無事成功！！！
- 投稿日：2020-10-19T17:44:12+09:00
Dockerとdocker-composeを ラズパイ4 と Linux(Debian) と Windows10 にそれぞれインストールする
最近勉強している、Docker と docker-compoesについて書きます。
本当は、同じDockerfile と ymlを用いて動作環境を作って便利さを実感するところまで書きたかったのですが、次回にしようと思います。まず、ラズパイ4にDockerとdocker-composeをインストール
ラズパイはARMだからか？、Linux版とはインストール方法が異なる。
環境
- ラズパイ4 + Rasbian10
1.前準備
1-1. パッケージの一覧を更新する
$ sudo apt-get update1-2. gitインストール
$ sudo apt-get install git-all1-3. curlインストール
$ sudo apt-get install curl2. Docker/docker-composeインストール
2-1. Dockerを取得しインストールする。
$ curl -sSL https://get.docker.com | sh $ docker -v Docker version 19.03.13, build 4484c46d9dversionが表示されれば、インストール成功。
2-2. Docker composeインストール
gitから取得した環境docker-compose instal shellを実行
$ git clone https://github.com/docker/compose.git $ cd compose $ git checkout 1.27.4 $ sudo ./script/build/linux $ cd dist $ sudo cp docker-compose-Linux-armv7l /usr/local/bin/docker-compose $ cd /usr/local/bin $ sudo chown root:root docker-compose $ sudo chmod 755 docker-compose $ docker-compose -v docker-compose version 1.27.4, build 40524192versionが表示されれば、インストール成功。
次、PC LinuxにDockerとdocker-composeをインストール
環境
- Debian10
1.前準備
ここはラズパイと同じため、省略
2. Docker/docker-composeインストール
2-1. Dockerを取得しインストールする。
$sudo apt-get -y remove docker docker-engine docker.io $sudo apt-get -y update $sudo apt-get -y install \ apt-transport-https \ ca-certificates \ curl \ gnupg2 \ software-properties-common $sudo curl -fsSL https://download.docker.com/linux/$(. /etc/os-release; echo "$ID")/gpg | sudo apt-key add - $sudo add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/$(. /etc/os-release; echo "$ID") \ $(lsb_release -cs) \ stable" $sudo apt-get update $sudo apt-get -y install docker-ce $docker -v Docker version 19.03.13, build 4484c46d9dversionが表示されれば、インストール成功。
2-2. Docker composeインストール
gitから取得した環境docker-compose instal shellを実行
$sudo curl -L https://github.com/docker/compose/releases/download/1.27.4/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose $sudo chmod +x /usr/local/bin/docker-compose docker-compose --version docker-compose version 1.27.4, build 40524192versionが表示されれば、インストール成功。
最後、Windows10
ほぼ、手動でやることはなかったので、ほぼ参照です。。
環境
- Windows10 + WSL2
※最終的に、VSCodeと連携するおデバッグ実行できてとても便利。1.前準備
1-1. Windowのバージョンを2004以降にする。
下記参照。
https://support.microsoft.com/ja-jp/help/4028685/windows-10-get-the-update1-2. WSL2をインストールする。
下記参照。
https://docs.microsoft.com/ja-jp/windows/wsl/install-win102.Docker DeskTopをインストール(Windows向けDocker、docker-compose環境)
2-.1 Docker DeskTopインストール
下記参照。
https://docs.docker.com/docker-for-windows/install/次回は、Dockerfile、ymlファイルを用意して実行するところを書きます。
- 投稿日：2020-10-19T17:24:57+09:00
Python で parameter store を使う
はじめに
以前、仕事で使った Parameter Store（AWS Systems Manager） をまた使うことになったので思い出しました。
今回もPoetry + Dockerを開発環境にしています。
ソースは Github にあげてあります。Parameter Store を設定する
/aaaで始まるように作成
ファイル
mainとライブラリとしてファイルを分けています。
main.pyfrom src.ssm_manager import SsmManager print("start") ssm_manager = SsmManager(region_name="ap-northeast-1") ssm_manager.load_parameter(base_ssm_path="/aaa") print(ssm_manager.parameters)ssm_manager.pyfrom typing import List, Dict import boto3 class SsmManager: def __init__(self, region_name: str): self.__ssm = boto3.client('ssm', region_name=region_name) self.__parameters = [] self.__base_ssm_path = None @property def parameters(self) -> List[Dict[str, any]]: return [{ 'name': item['Name'].replace(f'{self.__base_ssm_path}/', ''), 'value': item['Value'] } for item in self.__parameters] def load_parameter(self, base_ssm_path: str) -> None: self.__base_ssm_path = base_ssm_path result = [] next_token = None while True: dict_parameter = { 'Path': base_ssm_path, 'Recursive': True, 'WithDecryption': True, } if next_token is not None: dict_parameter['NextToken'] = next_token response = self.__ssm.get_parameters_by_path(**dict_parameter) parameters = response['Parameters'] result.extend(parameters) if 'NextToken' not in response: break next_token = response['NextToken'] self.__parameters = result終わりに
これで、環境変数などに入れていたRDSのパスワードなどを保存できます。
- 投稿日：2020-10-19T16:04:58+09:00
TAO Core をDockerで動かす
備忘録として
環境
macOS Catalina 10.15.7
docker desktop 2.4.0.0
TAO Core 3.3.0-RC2流れ
- ここからDLして解凍したフォルダに移動
- Terminalで
docker-compose buildを実行 するとエラーになった- エラーメッセージから
docker/phpfpm/Dockerfileの6行目、apt-getで色々installしている中にlibzstd-devを追記- 改めて
docker-compose buildを実行- 完了したら
docker-compose up -d- ブラウザで
http://localhostにアクセスでTAO Installation Wizardのページが開く。気になったこと
- 公式からDLしたのに素直にビルドできないとは
- Installation Wizardの最初にRequirements Checkが表示されるが、
Nginx is not officially supported.と言われる中身はまだ触っていないのでこれから
- 投稿日：2020-10-19T14:06:52+09:00
更新したDockerfileの再読み込みは何をすればいい？
- 投稿日：2020-10-19T12:44:58+09:00
まだVMで消耗してるの？ Dockerの良い所、関連用語の解説！
はじめに
Dockerはコマンド一発で環境構築でき、開発環境をそのまま本番環境に移せるツールです。
今回、簡単にDockerについて解説します！【YouTube動画】 まだVMで消耗してるの？ Dockerの良い所、関連用語を解説します！
VMとコンテナの違い
動画だとこの部分に相当します。
大きな違いはホストOS (いまメインで使ってるOS) 上で別のOSが動いているかどうかです。
VMではOSの上で別のOSが動いているので、動作が遅いです。
対して、コンテナ技術を使った仮想化では、今使ってるOS上で動かしているので、動作が早いです！ちなみにコンテナはDockerだけじゃなく、他にもcontainerdやpodmanなどいろんなものがあります。
Dockerの使い所
動画だとこの部分になります。
Dockerの利便性として、以下のようなものがあります。
- フロントエンドの実装だけする人や初心者が大変な環境構築を一発でできる
- CircleCIなどCIサービス
- イミュータブル・インフラストラクチャ (環境を毎回新しく作り直せる！)
-> パッチを当てて脆弱性を修正する必要がなくなります！もう開発にはなくてはならないツールですね。
Dockerの用語まとめ
Docker関連でよく見る単語について紹介しておきます。
動画だとこの部分です。
Docker Hub
Docker HubはDockerイメージを保存しておくリポジトリです。
ちなみに2020年11月から、半年間未使用のイメージが削除されるようになったので、気をつけてください (フリープランの人)。Dockerfile
作成するDockerイメージの設定を書いておくファイルです。
設定を書くと、RUNやADDなどの命令がある行ごとに中間イメージが作成されます。docker-compose
複数のDockerコンテナを連携するために使用します。kubernetes
発音は以下のサイトで確認ください。
https://www.youtube.com/watch?v=3uFqJ0IhxVAコンテナ運用の自動化をするために使います。
kとsの間に8文字あるので、k8sとか略されます。
Amazon ECR (Amazon Elastic Container Registry)
コンテナイメージをAWS上で管理するために使います。Amazon ECS (Amazon Elastic Container Service)
クラスターでコンテナ実行、停止、管理ができるサービスです。Amazon EKS (Amazon Elastic Kubernetes Service)
AWS上でk8sを運用するためのサービスです。Amazon Fargate
コンテナ向けのサーバレスサービスです。まとめ
Dockerについて興味をもっていただけたでしょうか？
もっと詳しく学びたいと思われた方は、以下のQiita記事が大変詳しいので、オススメします！
いまさらだけどDockerに入門したので分かりやすくまとめてみた
- 投稿日：2020-10-19T09:36:12+09:00
DockerでNuxt.js + TypeScript + Sassの環境構築
概要
nuxt.jsをdockerで動かすための環境を作ったので忘れない様に残しておきます。
環境
・macOS
・Docker for macファイル構成
最終的なファイル構成は以下の様な感じになります。
- docker - nuxt - Dockerfile - sample - nuxt.config.js - その他省略 - docker-compose.yml手順
Dockerfile作成
DockerfileFROM node:14.4.0-alpine WORKDIR /app RUN apk update && \ npm install -g npm && \ npm install -g @vue/cli && \ npm install -g @vue/cli-init ENV HOST 0.0.0.0 EXPOSE 3000 CMD ["/bin/ash"]docker-compose.yml作成
docker-compose.ymlversion: '3' services: nuxt: build: ./docker/nuxt ports: - 3000:3000 volumes: - .:/app stdin_open: true tty: trueイメージをビルド
$ docker-compose buildコンテナを立ち上げる
$ docker-compose up -d作成したコンテナ内に入ります
$ docker exec -it nuxt-docker_nuxt_1 /bin/shcreate-nuxt-appでnuxtプロジェクトを作成する
npxはインストールしていないパッケージを一度だけ実行できる機能があります。
$ npx create-nuxt-app sample色々な選択肢が出てきるので好きなのを選びましょう。
※そしてここでTypeScriptを選択すること。create-nuxt-app v3.1.0 ✨ Generating Nuxt.js project in sample ? Project name: sample ? Programming language: TypeScript ? Package manager: Npm ? UI framework: None ? Nuxt.js modules: (Press <space> to select, <a> to toggle all, <i> to invert selection) ? Linting tools: (Press <space> to select, <a> to toggle all, <i> to invert selection) ? Testing framework: Jest ? Rendering mode: Single Page App ? Deployment target: Server (Node.js hosting) ? Development tools: (Press <space> to select, <a> to toggle all, <i> to invert selection)インストールが無事完了したら下記のメッセージが出ます。
? Successfully created project sample To get started: cd sample npm run dev To build & start for production: cd sample npm run build npm run start To test: cd sample npm run test For TypeScript users. See : https://typescript.nuxtjs.org/cookbook/components/※TypeScriptの使い方についてはhttps://typescript.nuxtjs.org/cookbook/components/ を参照してくださいとのこと。
ガイドに沿ってnuxt.jsを立ち上げてみます。
$ cd sample $ npm run dev> nuxt ╭───────────────────────────────────────╮ │ │ │ Nuxt.js @ v2.13.3 │ │ │ │ ▸ Environment: development │ │ ▸ Rendering: client-side │ │ ▸ Target: server │ │ │ │ Listening: http://localhost:3000/ │ │ │ ╰───────────────────────────────────────╯ ℹ Preparing project for development 16:39:27 ℹ Initial build may take a while 16:39:27 ✔ Builder initialized 16:39:27 ✔ Nuxt files generated 16:39:27 ℹ Starting type checking service... nuxt:typescript 16:39:31 ✔ Client Compiled successfully in 11.52s ℹ Type checking in progress... nuxt:typescript 16:39:43 ℹ Waiting for file changes 16:39:43 ℹ Memory usage: 261 MB (RSS: 361 MB) 16:39:43 ℹ Listening on: http://localhost:3000/ 16:39:43 ℹ No type errors found nuxt:typescript 16:39:45 ℹ Version: typescript 3.8.3 nuxt:typescript 16:39:45 ℹ Time: 13999 ms無事立ち上がったようなのでhttp://localhost:3000/ にアクセスしてみます。
あれっ？
調べてみるとどうやら以下のserverの記述がnuxt.config.jsに必要なようです。
[参考]
https://qiita.com/arthur_foreign/items/bc87c9b66e7ea9710c6bnuxt.config.jsmode: 'spa', server: { port: 3001, // 3000でもいい host: '0.0.0.0', },再チャレンジ
$ npm run dev > nuxt ╭──────────────────────────────────────────╮ │ │ │ Nuxt.js @ v2.13.3 │ │ │ │ ▸ Environment: development │ │ ▸ Rendering: client-side │ │ ▸ Target: server │ │ │ │ Listening: http://192.168.0.11:3001/ │ │ │ ╰──────────────────────────────────────────╯ ℹ Preparing project for development 17:02:18 ℹ Initial build may take a while 17:02:18 ✔ Builder initialized 17:02:18 ✔ Nuxt files generated 17:02:18 ℹ Starting type checking service... nuxt:typescript 17:02:22 ✔ Client Compiled successfully in 3.93s ℹ Type checking in progress... nuxt:typescript 17:02:26 ℹ Waiting for file changes 17:02:26 ℹ Memory usage: 271 MB (RSS: 345 MB) 17:02:26 ℹ Listening on: http://192.168.0.11:3001/ 17:02:26 ℹ No type errors found nuxt:typescript 17:02:31 ℹ Version: typescript 3.8.3 nuxt:typescript 17:02:31 ℹ Time: 9546 ms
無事立ち上げることができました?
Sassの追加
プロジェクトのディレクトリにて追加でsass-loaderをnpm installしてあげればokです。
[参考]
https://ja.nuxtjs.org/faq/pre-processors/$ npm install --save-dev node-sass sass-loader
- 投稿日：2020-10-19T08:48:36+09:00
Docker + Django + Reactの環境構築
Dockerfile(Django用)
FROM python:3.9.0 ENV PYTHONUNBUFFERED 1 RUN mkdir /backend WORKDIR /backend ADD requirements.txt /backend/ RUN pip install -r requirements.txt ADD . /backend/Dockerfile-nodejs(React用)
FROM node:12.19.0 RUN mkdir /frontend WORKDIR /frontend RUN npm install -g create-react-apprequirements.txt
Django==3.1 psycopg2docker-compose.yml
version: '3' services: db: image: postgres environment: POSTGRES_PASSWORD: password django: build: . command: python3 manage.py runserver 0.0.0.0:8000 volumes: - ./backend:/backend ports: - "8000:8000" depends_on: - db react: build: context: . dockerfile: "./Dockerfile-nodejs" volumes: - .:/frontend command: > cd frontend && yarn start ports: - "3000:3000"
- 投稿日：2020-10-19T01:08:45+09:00
CentOS8にNginxを入れずにdockerでNginx起動
Qiiaに投稿してみるにあたり、自分のブログに掲載した内容をQiia向けに修正して投稿してみることに。画像挿入や見出しや引用など、修正する作業量は割と多かった。
CentOS8にNginxを入れずにNginx起動する
CentOS8にNginxを入れずにNginx起動することは可能だ。具体的にはdockerをインストールしてdockerを利用してNginxを起動する。
# nginx -V
CentOS8にはNginxをインストールしていないので、コマンドが見つかりませんでしたのメッセージ。その後にnginx のインストールを促してくるがNo。この状態でdockerをインストールしてdockerを利用してNginxを起動してみる。
CentOS8にdockerをインストール手順についての参照元
docs.docker.comのCentOSにDockerエンジンをインストールするを参考にしようかと思ったが、CentOS7を対象としており、CentOS8向けではなかった。そのため、CentOs8にdockerをインストールを参考にさせてもらいインストールの実施をすることにした。
CentOS8にdockerをインストール（失敗）
手順としては
①CentOSにDockerエンジンをインストールするを参考に、一応古いバージョンのアンインストールを実施
# dnf remove docker docker-client docker-client-latest docker-common docker-latest docker-latest-logrotate docker-logrotate docker-engine②CentOS Linuxのバージョン確認
# cat /etc/centos-release
CentOS Linux release 8.2.2004 (Core)③リポジトリの追加 確認
# dnf config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo④リポジトリの確認
# dnf repolist⑤DockerEngineのインストールを実施（失敗）
# dnf install --nobest docker-ce
CentOS8をインストール直後の状態では、古いバージョンのdockerアンインストールは対象が無かったので「①CentOSにDockerエンジンをインストールするを参考に、一応古いバージョンのアンインストールを実施」は飛ばしてもらって問題ない。CentOS8にdockerをインストール（成功）
競合するパッケージがあり、DockerEngineのインストールに失敗したので、警告通り競合するパッケージを置きかえるコマンドラインを追加して再度CentOS8にdockerのインストールを実施した
⑤DockerEngineのインストールを実施（成功）
# dnf install --nobest docker-ce --allowerasing
dockerインストールが成功したので
⑥dockerのバージョンを確認
# docker --version
Docker version 19.03.13, build 4484c46d9d⑦dockerの自動起動と起動設定
# systemctl enable docker
# systemctl start dockerを実施。
dockerを利用してNginxを起動する
⑧dockerを利用してNginxを起動
# docker run --name testnginx -d -p 8080:80 nginx⑨dockerのコンテナの状態の情報表示
# docker ps -a
docker runでnginxを「testnginx」という名前で<ホスト側のポート>:<コンテナ側のポート>を8080:80で実行している。
docker ps -aでコンテナの状態を表示すると
NAMESが「testnginx」PORTSが「0.0.0.0:8080->80/tcp」と、指定した条件で実行されているのが確認できる。なお後で確認することになるので、CONTAINER IDが「c917cab45486」で実行されていることにも注目しておいてほしい。Firefoxでlocalhost:8080にアクセス
Firefoxでlocalhost:8080にアクセスする。8080なのはdocker runで「-p 8080:80」と指定した為だ。
CentOS8にNginxを入れずにdockerを利用してNginx起動することに成功した。Dockerコンテナ、イメージを削除する
⑩dockerのコンテナ、イメージの停止
# docker stop c917cab45486⑪dockerのコンテナ、イメージを削除
# docker rm c917cab45486⑫dockerのコンテナの状態の情報表示
# docker ps -a
実行中のコンテナ、イメージを削除しようとするとエラーとなるので、事前にdocker stopでCONTAINER ID「c917cab45486」を指定して停止している。その後、docker rmで削除してdockerのコンテナ、イメージが無くなったことをdocker ps -aで確認している。
- 投稿日：2020-10-19T01:02:46+09:00
Windows環境上にLinuxを構築。laradockを導入してMigrationするまでの手順
開発環境
Laravel 7.20.0
PHP 7.4
MYSQL 8.0.21
Windows version 2004全体のおおまかな流れ
- Ubuntu導入
- WSL2に更新・導入
- dockerインストール
- laradock導入
本記事のゴール
本記事はWindows環境上にWSL2を用いてLinux環境を構築し、Laradockを導入して画面の表示+Migrationすることを目標としています。
まずはUbuntu導入準備から
Windowsを最新状態にアップデート（下記URLでダウンロード）
https://support.microsoft.com/ja-jp/help/4028685/windows-10-get-the-update
PCの設定から開発者モードに変更
• 「設定(スタートボタンの歯車アイコン)」-「更新とセキュリティ」-「開発者向け」を選択
• 「開発者向け機能を使う」欄の「開発者モード」を選択して有効化追加機能でSubsystem for Linuxを有効化
• 「コントロールパネル」-「プログラム」-「Windowsの機能の有効化または無効化」を選択
• 一覧のなかから「Windows Subsystem for Linux(Beta)」にチェックを入れるｗindows version2004の場合は表記が「Linux用Windowsサブシステム」に変更しているためそれを有効化してください。
PC再起動
Ubuntuのインストール
UbuntuとはLinuxディストリビューションの1つであり、フリーソフトウェアとして提供されている
Microsoft storeでubunntuをインストール。
コマンドプロンプトでbashと入力。（Ubuntuにログイン出来たら成功）
続いてUbuntuの状態を最新にします。
$ sudo apt-get update $ sudo apt-get dist-upgrade $ sudo apt-get autoremove
GitとPHPを取得
普通にインストールすると古いバージョンのGitがインストールされるので、リポジトリを追加して最新のものを取得。
下記コマンドを実行。
$ sudo apt-get install build-essential $ sudo add-apt-repository ppa:git-core/ppa $ sudo apt-get update $ sudo apt-get install git $ git --version //最新になっていたらOK git version 2.28.0
PHP
※PHP--version 7.4を指定しています。
＄sudo apt-get install php7.4 php7.4-fpm php7.4-mysql php7.4-mbstring php7.4-gd $ php -v //指定したバージョンがインストールされているかを確認 PHP 7.4.3 (cli) (built: May 26 2020 12:24:22) ( NTS ) Copyright (c) The PHP Group Zend Engine v3.4.0, Copyright (c) Zend Technologies with Zend OPcache v7.4.3, Copyright (c), by Zend Technologies
WSL2の事前準備
WSL2とはLinuxカーネルが動作する「本物のLinux環境」
「Windows PowerShell」の中の「Windows PowerShell」を「管理者として実行」して下記コマンドを実行
PS C:\>dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
PS C:\>dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
PCを再起動
バージョンの確認C:¥> ver Microsoft Windows [Version 10.0.19041.84]
バージョンが10.0.18917以上であることを確認
デフォルトをWSL2に設定するため、下記コマンドを実行。C:¥> wsl --set-version ubuntu 2WSL2に切り替わっているか確認。
C:¥> wsl -l -v NAME STATE VERSION * Ubuntu Stopped 2
WSL2を導入したのでDockerを構築するうえでの事前準備は完了
Dockerのインストール
DockerとはLinux コンテナの作成と使用を実現するオープンソースのコンテナ化技術
下記URLからDocker Desktop Edgeをインストール
https://docs.docker.com/docker-for-windows/wsl-tech-preview/
PC再起動
再起動後、タスクバーのdockerアイコンから「setting」を選択
「Enable the experimental WSL2 based engine」にチェックを入れ「Appli&Restart」をクリック再起動が終わってnotificationと表示されたらOK
続いて、ResourcesのWSLIntegration内の「Enable WSL Integration」をクリック
「Ubuntu」を選択して「Appli&Restart」をクリック
Dockerの動作確認
C:\Users\magic>wsl -d ubuntu $ docker -v Docker version 19.03.5, build 633a0ea838
####Hello Worldと表示されれば成功$ docker run hello-world To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. Hello from Docker!Laradock導入
本番環境に必要なパッケージを提供してくれる。Homesteadをより細かく分割したようなもの
前提
Laradockも含めて１プロジェクト１リポジトリで管理したいので下記構成。
──project_dir ├ app //laravel ディレクトリ │ ├ app │ │ bootstrap │ └ .env │ └ Laradock
Laradockをgit clone
$git clone https://github.com/Laradock/laradock.git
設定ファイル(env-exampl)をコピーして.envを生成
$ cd laradock $ cp env-example .env
コピーしたenv（Laradock.env）ファイルの編集
指定したいプロジェクトを指定
APP_CODE_PATH_HOST=../ APP_CODE_PATH_HOST=../プロジェクト名/
データの保存ディレクトリを指定
DATA_PATH_HOST=~/.laradock/data + DATA_PATH_HOST=.laradock/data
プロジェクト名の設定
laradockを使ったプロジェクトを複数作る場合、プロジェクト名が同じ場合、過去に作った同じ名前のコンテナイメージが上書きされてしまいまうため、被らない名前を設定
COMPOSE_PROJECT_NAME=laradock + COMPOSE_PROJECT_NAME=
MYSQLの設定
MySQLは8系になってパスワードの生成方法が変わったらしくLaravelから操作できないため下記記述を追記。
/lardock/mysqmy.cnfに下記を追加
// [mysqld]のエリアに追記する（デフォルトの場合一番下） default_authentication_plugin=mysql_native_password
Laravel.envの設定
DBの設定を合わせて変更します
※DB_HOSTはdocker-compose.ymlに書かれているコンテナ内名を指定します。DB_CONNECTION=mysql DB_HOST=mysql(既存だと127.001になっていると思うのでmysqlに修正) DB_PORT=3306 DB_DATABASE=default DB_USERNAME=default DB_PASSWORD=secret
Laradockの起動
下記コマンドでlaradockを起動します。 引数には起動したいミドルウェアを指定
なお、projectが存在しない場合はroot権限で作成されてしまうため、必ず作成した状態で起動すること
$ docker-compose up -d nginx mysql workspace
起動確認
$ docker-compose ps
Dockerコンテナ内からLaravelをインストール
dockerコンテナ内からlaravelをインストールする方法と、設定。
下記コマンドでWorkspaceコンテナに入る。
※userオプションでユーザを指定してください。
$ docker-compose exec --user=laradock workspace /bin/bash
コンテナ内で下記を実行してLaravelをインストール。
/var/www$ composer create-project --prefer-dist laravel/laravel .
インストール完了したところで動作確認。
（※3306portを他に使用している場合はportが競合するためタスクマネージャーなどでportを終了させてください）Windows側のブラウザで、http://localhostにアクセスします。
画面が表示されればインストール完了
マイグレーションの確認
MySQLの設定が完了したか、マイグレーションで確認してみましょう。下記のようにDBにテーブルが作成されれば成功
/var/www$ php artisan migrate Migration table created successfully. Migrating: 2014_10_１９000000_create_users_table Migrated: 2014_10１９000000_create_users_table (0.36 seconds) Migrating: 2014_10１９100000_create_password_resets_table Migrated: 2014_10１９100000_create_password_resets_table (0.35 seconds) Migrating: 2019１０19_000000_create_failed_jobs_table Migrated: 2019１０_19_000000_create_failed_jobs_table (0.1 seconds)
終わりに
今回はWindows環境にLaradockを導入するまでの流れを記事として投稿しました
それと来月でプログラミングを始めてから一年経つこともあり、当初よりも知見が深まったこともあるので、これから少しずつ技術記事を上げていこうと思います。
どうかよろしくお願いいたしますm(._.)m
- 投稿日：2020-10-19T01:02:46+09:00
Windows環境上にLinuxを構築。Laradockを導入してMigrationするまでの手順
開発環境
Laravel 7.20.0
PHP 7.4
MYSQL 8.0.21
Windows version 2004全体のおおまかな流れ
- Ubuntu導入
- WSL2に更新・導入
- dockerインストール
- laradock導入
本記事のゴール
本記事はWindows環境上にWSL2を用いてLinux環境を構築し、Laradockを導入して画面の表示+Migrationすることを目標としています。
まずはUbuntu導入準備から
Windowsを最新状態にアップデート（下記URLでダウンロード）
https://support.microsoft.com/ja-jp/help/4028685/windows-10-get-the-update
PCの設定から開発者モードに変更
• 「設定(スタートボタンの歯車アイコン)」-「更新とセキュリティ」-「開発者向け」を選択
• 「開発者向け機能を使う」欄の「開発者モード」を選択して有効化追加機能でSubsystem for Linuxを有効化
• 「コントロールパネル」-「プログラム」-「Windowsの機能の有効化または無効化」を選択
• 一覧のなかから「Windows Subsystem for Linux(Beta)」にチェックを入れるｗindows version2004の場合は表記が「Linux用Windowsサブシステム」に変更しているためそれを有効化してください。
PC再起動
Ubuntuのインストール
UbuntuとはLinuxディストリビューションの1つであり、フリーソフトウェアとして提供されている
Microsoft storeでubunntuをインストール。
コマンドプロンプトでbashと入力。（Ubuntuにログイン出来たら成功）
続いてUbuntuの状態を最新にします。
$ sudo apt-get update $ sudo apt-get dist-upgrade $ sudo apt-get autoremove
GitとPHPを取得
普通にインストールすると古いバージョンのGitがインストールされるので、リポジトリを追加して最新のものを取得。
下記コマンドを実行。
$ sudo apt-get install build-essential $ sudo add-apt-repository ppa:git-core/ppa $ sudo apt-get update $ sudo apt-get install git $ git --version //最新になっていたらOK git version 2.28.0
PHP
※PHP--version 7.4を指定しています。
＄sudo apt-get install php7.4 php7.4-fpm php7.4-mysql php7.4-mbstring php7.4-gd $ php -v //指定したバージョンがインストールされているかを確認 PHP 7.4.3 (cli) (built: May 26 2020 12:24:22) ( NTS ) Copyright (c) The PHP Group Zend Engine v3.4.0, Copyright (c) Zend Technologies with Zend OPcache v7.4.3, Copyright (c), by Zend Technologies
WSL2の事前準備
WSL2とはLinuxカーネルが動作する「本物のLinux環境」
「Windows PowerShell」の中の「Windows PowerShell」を「管理者として実行」して下記コマンドを実行
PS C:\>dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
PS C:\>dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
PCを再起動
バージョンの確認C:¥> ver Microsoft Windows [Version 10.0.19041.84]
バージョンが10.0.18917以上であることを確認
デフォルトをWSL2に設定するため、下記コマンドを実行。C:¥> wsl --set-version ubuntu 2WSL2に切り替わっているか確認。
C:¥> wsl -l -v NAME STATE VERSION * Ubuntu Stopped 2
WSL2を導入したのでDockerを構築するうえでの事前準備は完了
Dockerのインストール
DockerとはLinux コンテナの作成と使用を実現するオープンソースのコンテナ化技術
下記URLからDocker Desktop Edgeをインストール
https://docs.docker.com/docker-for-windows/wsl-tech-preview/
PC再起動
再起動後、タスクバーのdockerアイコンから「setting」を選択
「Enable the experimental WSL2 based engine」にチェックを入れ「Appli&Restart」をクリック再起動が終わってnotificationと表示されたらOK
続いて、ResourcesのWSLIntegration内の「Enable WSL Integration」をクリック
「Ubuntu」を選択して「Appli&Restart」をクリック
Dockerの動作確認
C:\Users\magic>wsl -d ubuntu $ docker -v Docker version 19.03.5, build 633a0ea838
####Hello Worldと表示されれば成功$ docker run hello-world To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. Hello from Docker!Laradock導入
本番環境に必要なパッケージを提供してくれる。Homesteadをより細かく分割したようなもの
前提
Laradockも含めて１プロジェクト１リポジトリで管理したいので下記構成。
──project_dir ├ app //laravel ディレクトリ │ ├ app │ │ bootstrap │ └ .env │ └ Laradock
Laradockをgit clone
$git clone https://github.com/Laradock/laradock.git
設定ファイル(env-exampl)をコピーして.envを生成
$ cd laradock $ cp env-example .env
コピーしたenv（Laradock.env）ファイルの編集
指定したいプロジェクトを指定
APP_CODE_PATH_HOST=../ APP_CODE_PATH_HOST=../プロジェクト名/
データの保存ディレクトリを指定
DATA_PATH_HOST=~/.laradock/data + DATA_PATH_HOST=.laradock/data
プロジェクト名の設定
laradockを使ったプロジェクトを複数作る場合、プロジェクト名が同じ場合、過去に作った同じ名前のコンテナイメージが上書きされてしまいまうため、被らない名前を設定
COMPOSE_PROJECT_NAME=laradock + COMPOSE_PROJECT_NAME=
MYSQLの設定
MySQLは8系になってパスワードの生成方法が変わったらしくLaravelから操作できないため下記記述を追記。
/lardock/mysqmy.cnfに下記を追加
// [mysqld]のエリアに追記する（デフォルトの場合一番下） default_authentication_plugin=mysql_native_password
Laravel.envの設定
DBの設定を合わせて変更します
※DB_HOSTはdocker-compose.ymlに書かれているコンテナ内名を指定します。DB_CONNECTION=mysql DB_HOST=mysql(既存だと127.001になっていると思うのでmysqlに修正) DB_PORT=3306 DB_DATABASE=default DB_USERNAME=default DB_PASSWORD=secret
Laradockの起動
下記コマンドでlaradockを起動します。 引数には起動したいミドルウェアを指定
なお、projectが存在しない場合はroot権限で作成されてしまうため、必ず作成した状態で起動すること
$ docker-compose up -d nginx mysql workspace
起動確認
$ docker-compose ps
Dockerコンテナ内からLaravelをインストール
dockerコンテナ内からlaravelをインストールする方法と、設定。
下記コマンドでWorkspaceコンテナに入る。
※userオプションでユーザを指定してください。
$ docker-compose exec --user=laradock workspace /bin/bash
コンテナ内で下記を実行してLaravelをインストール。
/var/www$ composer create-project --prefer-dist laravel/laravel .
インストール完了したところで動作確認。
（※3306portを他に使用している場合はportが競合するためタスクマネージャーなどでportを終了させてください）Windows側のブラウザで、http://localhostにアクセスします。
画面が表示されればインストール完了
マイグレーションの確認
MySQLの設定が完了したか、マイグレーションで確認してみましょう。下記のようにDBにテーブルが作成されれば成功
/var/www$ php artisan migrate Migration table created successfully. Migrating: 2014_10_１９000000_create_users_table Migrated: 2014_10１９000000_create_users_table (0.36 seconds) Migrating: 2014_10１９100000_create_password_resets_table Migrated: 2014_10１９100000_create_password_resets_table (0.35 seconds) Migrating: 2019１０19_000000_create_failed_jobs_table Migrated: 2019１０_19_000000_create_failed_jobs_table (0.1 seconds)
終わりに
今回はWindows環境にLaradockを導入するまでの流れを記事として投稿しました
それと来月でプログラミングを始めてから一年経つこともあり、当初よりも知見が深まったこともあるので、これから少しずつ技術記事を上げていこうと思います。
どうかよろしくお願いいたしますm(._.)m
- 投稿日：2020-10-19T00:20:51+09:00
Waypointを使ったアプリケーションの超簡単デプロイ
概要
2020年10月15日、HashiCorpがWaypointという新しいプロダクトを発表しました。
簡単に説明すると、デプロイ設定ファイル1つ書くだけで、Amazon EC2やECS、Google Cloud Run、Azure Container Instancesといったクラウド環境にワンライナーでビルドからデプロイまで出来てしまう凄いツールです。
機能
- Waypointは、AWSやGoogle、Azureといったプラットフォームにアプリケーションを構築・リリースするためのワークフローを提供する
waypointup upコマンドで、アプリケーションのビルドからデプロイ・リリースまでを一括で実行することができる- 現在サポートしているプラットフォーム
- Kubernetes
- HashiCorp Nomad
- Amazon ECS
- Google Cloud Run
- Azure Container Instances
- Docker
- Buildpacks
- Dockerfileが不要
- Waypointはアプリケーションの構成から最適なビルドパックを自動的に利用してDockerfileを生成する (1)
- アプリケーションデプロイ後、デプロイメントの検証やログ、コマンド実行などの機能を提供する
- WaypointでデプロイされたアプリケーションはLet's Encryptで生成されるTLS証明書を含む公開URLを発行する。これによりアプリケーションの動作を他のユーザーと簡単に共有可能となる
- デプロイごとにバージョンを含むURLが発行される (オプション機能のため無効化することも可能)
- アプリケーションのビルド・リリース状況を確認するためのUIを提供 (2)
クラウドネイティブなアプリケーションはECSやKubernetesといったコンテナ基盤で動かすことが多いですが、サービスの構成によってはデプロイ構成やコマンドが複雑化することは多々あります。
Waypointを使うことで設定ファイルは一言管理でき、アプリケーションはよりシンプルなワークフローでリリースサイクルを回すことが可能となるのです。凄い。検証
Mac環境で試してみました。マニュアル には手動やLinux環境でのセットアップ方法も書いてあります。
Waypointで公開されているサンプルアプリケーションをDockerで動かしてみます。初めにWaypointをbrewでインストールします。
$ brew tap hashicorp/tap $ brew install hashicorp/tap/waypointヘルプを見てみましょう。
% waypoint --help Welcome to Waypoint Docs: https://waypointproject.io Version: v0.1.2 Usage: waypoint [-version] [-help] [-autocomplete-(un)install] <command> [args] Common commands build Build a new versioned artifact from source deploy Deploy a pushed artifact release Release a deployment up Perform the build, deploy, and release steps for the app Other commands artifact Artifact and build management config Application configuration management context Server access configurations deployment Deployment creation and management destroy Delete all the resources created for an app docs Show documentation for components exec Execute a command in the context of a running application instance hostname Application URLs init Initialize and validate a project install Install the Waypoint server to Kubernetes, Nomad, or Docker logs Show log output from the current application deployment runner Runner management server Server management token Authenticate and invite collaborators ui Open the web UI version Prints the version of this Waypoint CLI先ほど紹介した
waypoint upコマンドは、waypoint build、waypoint deploy、waypoint relaseを一括実行するコマンドであることが分かります。続いてサンプルアプリケーションをダウンロードします。サンプルの中にはDockerのほか、Amazon ECSやGoogle Cloud Runにデプロイするコードが含まれています。
$ git clone https://github.com/hashicorp/waypoint-examples.git $ cd waypoint-examples $ ls README.md azure-container-instance google-cloud-run waypoint.hcl aws-ecs data.db kubernetes aws-eks docker nomad # 今回はDocker上でNode.jsを動かしてみます $ cd docker/nodejsWaypointサーバーをインストールします。Waypointサーバーはアプリケーションのワークフローを管理するコンソールです。
$ docker pull hashicorp/waypoint:latest $ waypoint install -platform=docker -accept-tosアプリケーションをデプロイするにはデプロイ設定ファイルが必要となります。これは
waypoint initというコマンドで作成できますが、サンプルアプリケーションではファイルが作成されています。waypoint.hclproject = "example-nodejs" app "example-nodejs" { labels = { "service" = "example-nodejs", "env" = "dev" } build { use "pack" {} } deploy { use "docker" {} } }アプリケーションを初期化します。
$ waypoint init ✓ Configuration file appears valid ✓ Connection to Waypoint server was successful ✓ Project "example-nodejs" and all apps are registered with the server. ✓ Plugins loaded and configured successfully ✓ Authentication requirements appear satisfied. Project initialized! You may now call 'waypoint up' to deploy your project or commands such as 'waypoint build' to perform steps individually.そしてデプロイ。アプリケーションのディレクトリ構成を見ても分かりますが、Dockerfileがないことに気付くはずです。どうやってビルドしてるのかというと、Waypointがファイル構成からアプリケーションタイプを自動検出し、最適なビルドパックを利用してDockerfile自体を自動生成してるのです。賢い。
$ waypoint upビルドには時間がかかるので、この間にWaypointのUIを立ち上げてみましょう。
$ waypoint uiブラウザでWaypointのコンソールが立ち上がります。
初めに認証トークンを求められるので、CLIからトークンを発行しましょう。
生成された値をフォームに貼り付けることで認証済みとなります。$ waypoint token new
example-nodejsの画面が開きます。この画面からビルド状況やデプロイログ、更にはコンテナへのコマンド実行などが可能となります。
CLIに戻り、先ほどのビルド状態を確認してみます。
$ waypoint up » Building... Creating new buildpack-based image using builder: heroku/buildpacks:18 ✓ Creating pack client ✓ Building image │ [exporter] Adding 1/1 app layer(s) │ [exporter] Reusing layer 'launcher' │ [exporter] Adding layer 'config' │ [exporter] Adding label 'io.buildpacks.lifecycle.metadata' │ [exporter] Adding label 'io.buildpacks.build.metadata' │ [exporter] Adding label 'io.buildpacks.project.metadata' │ [exporter] *** Images (e2a2e3a85138): │ [exporter] index.docker.io/library/example-nodejs:latest │ [exporter] Reusing cache layer 'heroku/nodejs-engine:nodejs' │ [exporter] Reusing cache layer 'heroku/nodejs-engine:toolbox' ✓ Injecting entrypoint binary to image Generated new Docker image: example-nodejs:latest » Deploying... ✓ Setting up waypoint network ✓ Starting container » Releasing... The deploy was successful! A Waypoint deployment URL is shown below. This can be used internally to check your deployment and is not meant for external traffic. You can manage this hostname using "waypoint hostname." URL: https://***.waypoint.run Deployment URL: https://***--v1.waypoint.run
Deployment URLに書かれたURLを開くとアプリケーションが起動します。(3)
デプロイが成功したので、表示されているテンプレートの中身を書き換えてみます。
views/pages/index.js<h1>This Node.js app was deployed with Waypoint.</h1> <h2>Hello world!</h2>
<h1>の下に<h2>を追加してみました。
再度デプロイを実行します。URL: https://***.waypoint.run Deployment URL: https://***--v2.waypoint.run
Deployment URLに含まれるサブドメインがv2に変わってます。
正しく
Hello Worldが表示されました! (4)軽く触ってみた感じ、AWSのElastic Beanstalkのようなデプロイを抽象化するソフトウェアという印象を受けました。Waypointを導入することでアプリケーション構成からデプロイフローを分離でき、各種サービスのリリース状況を一元管理することができそうです。
アプリケーションディレクトリで
Dockerfileを検出した場合はビルド時に使用されるようです ↩チームで開発する場合はWaypointサーバーを構築する必要があります ↩
waypoint.runはHashiCorpが提供するパブリックなホストです。検証用環境のため、本番運用にはホストを用意する必要があります。詳しくは Waypoint URL Service を参照してください ↩
v1のURLにアクセスすれば以前のアプリケーションを開くこともできます ↩
