目次 1日目 - 初期構成 2日目 - /docsの作成 3日目 - DBとModelの作成 4日目 - CRUDの作成 5日目 - ユーザの認証の追加 6日目 - テストの導入 色々と仕様や導入方法などを調べていたらだいぶ時間が経ってしまったが、 前回大体の機能の実装ができたので、まずはテストを導入していく テストの実行 とりあえずテストを実行するまで ライブラリの導入 backendの環境の中に入って以下でpytestをインストールする bash poetry add pytest テストの実行 backendの環境内に入って以下のコマンドでテストを実行できる bash poetry run pytest テスト前の準備 今までずっと無視していたがpytestを行う上で各ディレクトリにinit.py（ディレクトリをライブラリとして認識するための空ファイルらしい）を作成する必要があるので、今まで作った以下のディレクトリにinit.pyの空ファイルを作っておく。 backend/api/__init__.py backend/api/v1/__init__.py backend/api/v1/tests/__init__.py テストの作成 一旦/のルーティングにあるhalloworldのレスポンスを返すエンドポイントのテストを書いていく テストファイルを以下のように作成する。 (テストファイルはファイル名をtest_***のようにするのが慣例らしい) api/v1/tests/test_main.py from fastapi.testclient import TestClient from api.v1.main import app client = TestClient(app) def test_root_path(): response = client.get('/') assert response.status_code == 200 FastApiで用意されているTestClientを利用してappに対して各リクエストをテストし、responseの内容をチェックしていくことでテストを行なっていくことができる。 データベースを利用したテスト データベースを利用したテストを行なっていく場合、テスト用のDBを用意する必要がある。 今回はsqliteを利用する。 今までrouter内でDBを利用する際はget_dbというメソッドを依存注入していたのがここで効いてくる。 test用のconfファイルとしてtestconf.pyを以下のように作成する。 api/v1/tests/testconf.py import pytest from fastapi.testclient import TestClient from sqlalchemy import create_engine from sqlalchemy.exc import SQLAlchemyError from sqlalchemy.orm import Session, sessionmaker from sqlalchemy.orm.session import close_all_sessions from api.v1.main import app from api.v1.db import get_db class TestingSession(Session): def commit(self): # commitをオーバーライドする self.flush() self.expire_all() @pytest.fixture(scope="function") def test_db(): engine = create_engine("sqlite:///./test_sqlite.db",connect_args={"check_same_thread":False}) TestSessionLocal = sessionmaker(class_=TestiongSession,autocommit=False,autoflush=False,bind=engine) db = TestSessionLocal() def get_test_db(): try: yield db db.commit() except SQLAlchemyError as e: assert e is not None db.rollback app.dependency_overrides[get_db] = get_test_db yield db db.rollback() close_all_sessions() engine.dispose() これでこのメソッドを先程のTestClientから作成したclientの引数に撮ることでget_dbをオーバーライドしてテスト時はsqliteを利用するように変更することができる。 テスト用のDBに各テーブルを作成する このままだと何のテーブルもないDBなので、ここでテーブルを作成する記述を追加する api/v1/tests/testconf.py # ~~~ from api.v1.models import user, post, lgtm # ~~~ def test_db(): engine = create_engine("sqlite:///./test_sqlite.db",connect_args={"check_same_thread":False}) user.Base.metadata.create_all(bind=engine) post.Base.metadata.create_all(bind=engine) lgtm.Base.metadata.create_all(bind=engine) TestSessionLocal = sessionmaker(class_=TestingSession,autocommit=False,autflush=False,bind=engine) # ~~~ これで各Modelに対応するテーブルが作成できる テストを作成 DBを利用したエンドポイント(GET /user/{login_id})のテストを書いてみる api/v1/tests/routers/test_user.py from fastapi.testclient import TestClient from api.v1.main import app from api.v1.tests.testconf import test_db from api.v1.models.user import User client = TestClient(app) def test_get_user_path(test_db): user1 = User(login_id="test_user_1",name="TestUser1",password_hash="unsecurepass") user2 = User(login_id="test_user_2",name="TestUser2",password_hash="unsecurepass") test_db.add_all([user_1,user_2]) response = client.get(f'/user/{user1.login_id}') assert response.status_code == 200 assert response.json()["login_id"] == "test_user_1" assert response.json()["name"] == "TestUser1" assert response.json()["password_hash"] is None これでDBを利用したケースのテストが書けるようになった。 ちなみにPostメソッドなどのリクエストにbodyをつけるようなリクエストの場合は以下のように書く。 response = client.post('/users',json={ "login_id":"test_user", "name":"TestUser", "password":"unsecurepass", "description":"fugafugafuga" }) multipart/form-dataなどの情報をリクエストするときはこんな感じ response = client.post('/token',data={ "username":"hogehoge", "password":"fugafuga" }) 認証が必要なエンドポイントへのテスト 認証を通した状態を再現するためにtestconf.pyにメソッドを追加する。 api/v1/tests/testconf.py # ~~~ import api.v1.cruds.auth as crud_auth # ~~~ def authorized_client(client:TestClient,user.User): access_token = crud_auth.create_access_token(data={"sub":user.login_id}) client.headers = { **client.headers, "Authorization":f"Bearer {access_token}" } return client def deauthorized_client(client:TestClient): del client.headers["Authorization"] return client テストの作成 認証が必要なPost /postsへのテストを作成する api/v1/tests/test_post.py from fastapi.testclient import TestClient from api.v1.main import app from api.v1.tests.testconf import test_db,authorized_client,deauthorized_client from api.v1.models.user import User from api.v1.models.post import Post client = TestClient(app) def test_post_posts_path(test_db): user_1 = User(login_id="test_user1",name="TestUser1",password_hash="unsecurepass") test_db.add(user_1) test_db.flush() test_db.commit() authorized_client(client,user_1) before_count = test_db.query(Post).count() response = client.post("/posts",json={ "title":"hogehoge", "context":"fugafugafugafuga" }) after_count = test_db.query(Post).count() assert response.status_code == 200 assert after_count-before_count == 1 assert response.json()["title"] == "hogehoge" assert response.json()["context"] == "fugafugafugafuga" assert response.json()["user"]["login_id"] == "test_user1" deauthorized_client(client) これで認証を通した状態でのテストが書けるようになった。 大体のテストはこのパターンで書けるので、これを参考に他のエンドポイントへのテストを追加していく。 backendの実装はあとはバリデーション周りの実装を行えば、次はフロントエンドに手をつけられそう。

コンテナのコマンド一覧 ＊イメージの作成 docker image build -t タグ名　参照する場所 ＊docker run(create)でマウント(※マウントとは「渡すこと」) docker run(create) -v ホストのパス：コンテナのパス　イメージ名 ＊コンテナの作成・起動 docker container run -d -p ():() --name つけたいコンテナ名　タグ名 ※-dはバックグラウンド上でコンテナを起動させるコマンド *コンテナの停止 docker container stop コンテナ名 *コンテナの削除 docker container rm コンテナ名 *未使用コンテナの削除 docker system prune -a おまけ *ログの確認 docker container logs コンテナ名 *起動中のコンテナ中で別のコマンドを実行する方法 docker container コンテナ名　実行したいコマンド

コンテナのコマンド一覧 ＊イメージの作成 docker image build -t タグ名　参照する場所 ＊コンテナの作成・起動 docker container run -d -p ():() --name つけたいコンテナ名　タグ名 ※-dはバックグラウンド上でコンテナを起動させるコマンド *コンテナの停止 docker container stop コンテナ名 *コンテナの削除 docker container rm コンテナ名 *未使用コンテナの削除 docker system prune -a おまけ *ログの確認 docker container logs コンテナ名 *起動中のコンテナ中で別のコマンドを実行する方法 docker container コンテナ名　実行したいコマンド

1,development.rbの記述を変えます config.file_watcher = ActiveSupport::EventedFileUpdateChecker config.file_watcher = ActiveSupport::FileUpdateChecker Eventedを削除 2,コンテナ再起動 docker-compose down -v docker-compose up -d docker-compose run web rails db:create docker-compose exec web bundle exec rails db:migrate これで無事反映されました！ ※再起動などは不要かもしれませんが自分の場合書き換えだけだと変わりませんでした

Docker で Next.js を起動する docker-compose.yml のみで Next.js を起動しようと試みたところ、どうやら npm のバージョンが対応していないようで起動するのが面倒だったので、docker compose up -dのみでサーバーを起動させるまでを行いたいと思います。 原因 Docker の npm のバージョンはデフォルトで 8.1.2 となっていました。 npm run devをすると以下のようになります > dev > next dev sh: 1: next: not found これをnpm upgradeで 8.3.0 にすると起動しました。 ディレクトリ構成 app ├ Dockerfile | ├ docker-compose.yml | └ nextプロジェクト Dockerfile Dockerfile FROM node:17.3.1 WORKDIR /usr/src/app/next COPY /react/package*.json ./ RUN npm install docker-compose.yml docker-compose.yml version: "3" services: next: build: . ports: - "3000:3000" container_name: "next" volumes: - ./react:/usr/src/app/next command: "npm run dev" 以上のようにして docker-compose.yml のあるディレクトリに移動し、docker compose up -dを行うと、localhost:3000 で作成した Next.js プロジェクトにアクセス可能になりました。

DockerのPostgreSQLが立ち上がらなくなった 昨日まで普通に立ち上がっていたのに。。 出たエラー django.db.utils.OperationalError: could not translate host name "db" to address: Name or service not known 対処 docekrでのゴミを削除する docker-compose down docker system prune めちゃくちゃ削除された。 正常に立ち上げるようになりました。

操作環境 OS：Windows10 使用ターミナル：WindowsPowerShell、コマンドプロンプト 環境構築ソフト：Docker 課題 　ある朝、いつものようにDockerでコンテナを立ち上げてPHPファイルを実行しようとしたところ、コンテナは立ち上がっているものの、PHP実行用のコンテナが起動していません。 　デーモンさん（サーバー側で、クライアントからの要求に応じるために常駐している門番のようなプログラムのこと）からは、「50080のポートにアクセスしようとしましたが、上手くいきませんでした」と言われている様子。 　$ docker-compose ps、 docker-compose logs コンテナ名　でコンテナの状況を確認しても、「STATUS: created」とあるものの、やはり起動はしていない。（起動していたら「running」となります。） 　Dockerのアプリの画面から起動ボタンを押しても、「ポート番号80が使われています。」という趣旨のエラーが画面上部に表示され、イメージを起動できません。 解決手順 　まず、ポート番号80をどのアプリケーションが使用しているのか調べるために、コマンドプロンプトで、$ netstat -nao　と入力し、実行します。 　すると、次のように、ローカルアドレスや外部アドレス、状態や使用されているプロトコル（ネット上の通信の際の決まり事のようなもの）の一覧が表示されます。（-naoのnは「IPアドレスとポート番号を数字で表示」、aは「LISTENING状態にあるTCPポートも表示」、oは「プロセス状態を表示」という意味のコマンドです。） 　ポート番号は外部アドレスの一番最後の部分で表されるので、末尾が80のものを探すと、...ありました！！ 　ここに表示されているPID(プロセスID)から、このポート番号80を使用しているアプリケーションを調べます。 　タスクバーにあるWindowsマークを右クリック→タスクマネージャー→詳細　で、アプリケーションの名前やPIDなどが載っている一覧が表示されます。この中から、先ほど調べたPID0のアプリケーションを探します。 　すると、Pythonの標準機能として搭載されている、IDLEがどうやらポート番号80と通信していることが分かりました。 　さて、次は、IDLEで行われている通信を切断！！...としたいところだったのですが、試しに先ほどのDockerのコンテナを起動しようとしたら起動できました。もしかしたら最初は何らかしらの通信がIDLEの方で行われていたものの、そのプロセスが数分間のうちに終了したのかもしれませんね。ちなみにSystem Idle Processの状態は今も「実行中」のままです。何はともあれ、とりあえず一件落着でめでたしめでたし。 総論 　ということで、今回は途中で解決してしまったため、使用されているポートの確認まででしたが、インターネットの勉強で出てきていたデーモン、ポート、プロトコルなどが実際にどのように使われているのか確認でき、良い経験になりました。 　今後もポートの重複などでトラブルが発生した時は、この手順で状態を確認することができそうです。 　それではまた次回の記事までごきげんよう！！ 参考 独学エンジニア（実際の内容は有料会員のみ見れます。） https://dokugaku-engineer.com/

初心者の自分なりに解決方法を見つけたので、メモ用として記載しておきます。 OS:　Windows10 にてエラーを確認（macは持っていないので同様の処理でうまくいくかは不明です。） 症状 インストール時に下記のエラー表記が出る failed to solve: rpc error: code = Unknown desc = executor failed running [/bin/sh -c apt-get update && apt-get install -y gnupg gosu curl ca-cer tificates zip unzip git supervisor sqlite3 libcap2-bin libpng-dev python2 && mkdir -p ~/.gnupg && chmod 600 ~/.gnupg && echo "disable-ipv 6" >> ~/.gnupg/dirmngr.conf && apt-key adv --homedir ~/.gnupg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys E5267A6C && apt-key adv - -homedir ~/.gnupg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys C300EE8C && echo "deb http://ppa.launchpad.net/ondrej/php/ubuntu hirsute main" > /etc/apt/sources.list.d/ppa_ondrej_php.list && apt-get update && apt-get install -y php8.1-cli php8.1-dev php8.1-pgsql php8.1- sqlite3 php8.1-gd php8.1-curl php8.1-imap php8.1-mysql php8.1-mbstring php8.1-xml php8.1-zip php8.1-bcmath php8.1-soap ph p8.1-intl php8.1-readline php8.1-ldap php8.1-msgpack php8.1-igbinary php8.1-redis php8.1-swoole php8.1-memcached php8.1-pcov php 8.1-xdebug && php -r "readfile('http://getcomposer.org/installer');" | php -- --install-dir=/usr/bin/ --filename=composer && curl -sL https:/ /deb.nodesource.com/setup_$NODE_VERSION.x | bash - && apt-get install -y nodejs && npm install -g npm && curl -sS https://dl.yarnpkg.com/ debian/pubkey.gpg | apt-key add - && echo "deb https://dl.yarnpkg.com/debian/ stable main" > /etc/apt/sources.list.d/yarn.list && apt-get upd ate && apt-get install -y yarn && apt-get install -y mysql-client && apt-get install -y postgresql-client && apt-get -y autoremove && apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*]: exit code: 100 対策 ターミナルにて下記を実施 "docker-compose build --no-cache" この間でエラー起きて止まる可能性がある、自分は[8/11]の時にエラー吐いて止まった。 ./vendor/bin/sail up -d エラー起きて止まっても上記を実施。 Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them [+] Running 10/10 ⠿ Network mybbs_sail Created 0.9s ⠿ Volume "mybbs_sailredis" Created 0.0s ⠿ Volume "mybbs_sailmeilisearch" Created 0.0s ⠿ Volume "mybbs_sailmysql" Created 0.0s ⠿ Container mybbs_meilisearch_1 Started 4.0s ⠿ Container mybbs_selenium_1 Started 3.6s ⠿ Container mybbs_mysql_1 Started 4.5s ⠿ Container mybbs_redis_1 Started 3.6s ⠿ Container mybbs_mailhog_1 Started 4.8s ⠿ Container mybbs_laravel.test_1 Started 上のような表記が出れば処理は完了しています。 最後に 下記にアクセスしLaravelの公式サイトが表示されれば完了 http://localhost:8573/ ※正直まだまだDockerの事が詳しくないので分からない事だらけですが、Youtubeや学習サイト等でチュートリアル形式の動画で 環境構築の練習をしている際にも言語問わずエラーが出まくるので、Docker嫌いになりそうです・・・。 機能面では優れものだと分かっているのですが、そこに到達するまでが鬼畜過ぎます。やっぱりMacの方が使いやすいのかな？