20210513のdockerに関する記事は10件です。

Djangoアプリ上でFessを使って検索窓を設置する

はじめに Djangoでサイトを作っていた際に、検索機能を手軽に設置したいなぁと思い、 OSSの検索エンジン Fess を使って実現したので方法を共有します。 Fessについて知りたい方は こちら をご参照ください。 想定読者 Djangoでのアプリケーション開発手法を理解している Docker / docker-compose の最低限の使用法について理解している Nginxの最低限の設定方法について理解している 構成 docker-composeにて以下コンテナを起動します。 nginxコンテナ djangoコンテナ postgresqlコンテナ fessコンテナ elasticsearchコンテナ 以下は docker-compose.yml の例です。 なお、fessとelasticsearchの設定についてはこちらのGithubを参考にさせていただきました。 また、ディレクトリ構成などは各開発状況に依存します。 docker-compose.yml version: '3.7' services: nginx: image: nginx:1.19.3-alpine ports: - "80:8000" volumes: - ./nginx/conf:/etc/nginx/conf.d - ./nginx/uwsgi_params:/etc/nginx/uwsgi_params - ./nginx/log:/var/log/nginx - ./app/static:/static depends_on: - django django: build: ./app command: uwsgi --socket :8001 --module app.wsgi --py-autoreload 1 volumes: - ./app/:/usr/src/app/ ports: - 8001:8001 depends_on: - postgres - fess postgres: image: postgres:12.4-alpine volumes: - ./postgres/data:/var/lib/postgresql/data fess: image: ghcr.io/codelibs/fess:13.12.0 environment: - "ES_HTTP_URL=http://es:9200" - "FESS_DICTIONARY_PATH=/usr/share/elasticsearch/config/dictionary/" ports: - "8080:8080" depends_on: - es es: image: ghcr.io/codelibs/fess-elasticsearch:7.12.0 environment: - node.name=es01 - discovery.seed_hosts=es01 - cluster.initial_master_nodes=es01 - cluster.name=fess-es - bootstrap.memory_lock=true - "ES_JAVA_OPTS=-Xms1g -Xmx1g" - "FESS_DICTIONARY_PATH=/usr/share/elasticsearch/config/dictionary" ulimits: memlock: soft: -1 hard: -1 nofile: soft: 65535 hard: 65535 volumes: - ./elasticsearch/data:/usr/share/elasticsearch/data - ./elasticsearch/dictionary:/usr/share/elasticsearch/config/dictionary ports: - 9200:9200 ただし、これで docker-compose up すると 「elasticsearch が立ち上がってないから fess が落ちたよ!」 と言われることがあります。 depends_onで指定はしていますが、内部の起動タイミングが合わないことがあるようです。 先にelasticsearchだけ立ち上げておけばよいのですが、よい解決法がありましたら教えてください。 Djangoのテンプレートへの検索窓追加 こちらのサンプルに従って検索窓をtemplateに配置します。 以下はサイトのURLが https://yoursite.co.jp の場合の例です。 <form id="searchForm" method="get" action="https://yoursite.co.jp/search/"> <input required pattern=".*\S+.*" id="query" type="text" name="q" maxlength="1000" autocomplete="off"> <input type="submit" name="search" value="検索"> </form> サンプルとの差分としては、required pattern=".*\S+.*" の部分です。 これがないと空、またはスペースのみの状態で検索ボタンが押せるのですが、 空で検索するとなぜか私の環境の場合はエラー画面となってしまったので追加しています。 Nginxの設定ファイル修正 フロントからのリクエストパスに応じて振り分けていきます。 以下の例では、/static, /admin/ などのDjangoのパスをまず設定し、 Fess関連のパスをfessコンテナに転送しています。 (とりあえず見つけた範囲を設定していますが他にもあるかもしれません) 最後にそれ以外のパスをdjangoコンテナに転送しています。 (Fess関連のパスがDjangoのパスと重複しないようにする必要があります) nginx.conf upstream django { ip_hash; server django:8001; } server { listen 8000; server_name 127.0.0.1; charset utf-8; location /static { alias /static; } location /admin/ { deny all; } location /search/ { proxy_pass http://fess:8080/search/; } location /css/ { proxy_pass http://fess:8080/css/; } location /js/ { proxy_pass http://fess:8080/js/; } location /images/ { proxy_pass http://fess:8080/images/; } location /go/ { proxy_pass http://fess:8080/go/; } location /cache/ { proxy_pass http://fess:8080/cache/; } location / { uwsgi_pass django; include /etc/nginx/uwsgi_params; } } server_tokens off; Fessの設定 ブラウザで http://[IP address]:8080 にアクセスするとFessの画面が表示されます。 ログインすると管理画面が表示されますので、クロールの設定やスケジューラの設定をしてください。 詳細はFess公式サイトに記載されていますので、自分がハマったところだけ記載しておきます。 (以下はすごく素人的なハマりだと思いますので、熟練者の方は生暖かく見守りください) Fessからのクロール先のURLはlocalhostでは機能しません。 なぜなら、fessコンテナから見たlocalhostは、通常fessコンテナ自身を表すからです。 また、クロール先を http://django:8001 や http://nginx:8000 にすると一見インデックスが作成されているように見えます。 しかし、検索結果のリンクURLも上記アドレスとなってしまうため、検索結果からサイトにアクセスできません。 こちらコメントにて「パスマッピング」の設定をすればよいとのご指摘をいただきました! なので、クロール先は https://yoursite.co.jp にしましょう。 この場合、クロールのリクエストは一旦外に出ることになります。 マシンのFW等でIP制限をしている場合は、マシン自体のグローバルIPを指定しないとはじかれてしまうので注意が必要です。 その他はまりどころ 以下の設定(Ubuntu 20.04の例)をしないとelasticsearchコンテナが落ちます。 $ sudo sysctl -w vm.max_map_count=262144
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Dockerでデュアルロギングができるようになっていた件

結論 Docker 20.10からロギングドライバを json-file / journald 以外にしても、 docker logs コマンドでコンテナログが見れます。(デュアルロギングというらしい) 詳細はこちら 背景 Dockerコンテナのログを見るコマンドとして docker logs がありますが、 例えばログをAWSやGCPに流したいとか、Fluentdに流したいとすると 「ロギング・ドライバ」というものを変更すればよいとのことでした。 そこで、「docker ロギングドライバ」とググると、以下のページに辿りつきます。(2021年5月時点) ロギング・ドライバの設定(Docker-docs-ja 19.03) このページを眺めていると ロギング・ドライバの制限 という項目があり、 Docker Community Engine を使う場合は、 docker logs コマンドは以下のドライバのみ利用可能です。 - local - json-file - journald と記載されており、実際これまでは上記以外のロギングドライバを指定した状態で docker logs をすると $ docker logs Error response from daemon: configured logging driver does not support reading みたいな表示がされていました。 例えば私はGCPにログを流していたので、GCPのログドライバでも調べたのですが、やはり This log driver does not implement a reader so it is incompatible with docker logs. と記載されていました。(将来的にアップデートされると思います) ところがDockerをアップデートして触っていると、 指定したロギングドライバの出力をした状態でも docker logs でログが出ることに気づきました。 最初はバグかと思っていろいろ試していたのですが、 結局のところDockerのリリースノートにたどり着き、 Support reading docker logs with all logging drivers (best effort) つまり「すべてのロギングドライバと一緒にdocker logsが読めるよ!」というアップデートがあったことに気づきました。 やはり docker logsはデバッグには便利なので、非常にありがたいアップデートだと思います。 最後に Docker 20.10がリリースされたのが2020年12月なので、 既に5か月経過しており「知ってるわ!」という方も多いと思いますが、 まだアップデートしてない方などの参考になれば幸いです。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

docker公式Alpine Linuxイメージを使ってmini_httpdでCGIを動かす

環境 Dockerホスト - Alpine Linux 3.13.5 #ESXi上に組みましたが、本質的にUbuntuでも何でも変わらないです。ちなみにメモリ384MB、HDD8GBです Dckerバージョン - 20.10.6 Dockerイメージ - alpine:3.13.5 mini_httpd - 1.30-r1 操作 Dockerホストでの操作 Dockerのインストール dockerイメージのあるリポジトリを有効にします。 /etc/apk host:~#vi repositories #/media/cdrom/apks http://dl-cdn.alpinelinux.org/alpine/v3.13/main #http://dl-cdn.alpinelinux.org/alpine/v3.13/community #http://dl-cdn.alpinelinux.org/alpine/edge/main http://dl-cdn.alpinelinux.org/alpine/edge/community <== '#'を削る http://dl-cdn.alpinelinux.org/alpine/edge/testing <== '#'を削る で、いつものおまじない。 host:~# apk update host:~# apk upgrade そしてDockerをインストールします。 host:~# apk add docker host:~# rc-update add docker boot host:~# service docker start 再起動したら動作確認します。 host:~# docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE と出ればok。「dockerサービスが動いてないよ」というエラーが出たらrebootしてみてください。 で、サクッとalpineなコンテナを作って中に入ります。 host:~# docker container run -dit --name miniweb --hostname miniweb alpine:3.13.5 tail -f /dev/null host:~# docker container exec -it miniweb /bin/ash "miniweb"部分は適当に変えてください。 Dockerイメージでの操作 いつものおまじない。 miniweb:~# apk update miniweb:~# apk upgrade そしてopenRCとmini_httpdをインストールします。 miniweb:~# apk add openrc miniweb:~# mkdir /run/openrc miniweb:~# touch /run/openrc/softlevel miniweb:~# apk add mini_httpd mini_httpdの設定ファイルを修正します。最低限必要なのはこれだけ。 /etc/mini_httpd miniweb:~# vi mini_httpd.conf port=80 user=minihttpd data=/var/www/localhost/htdocs cgipat=**.sh|**.cgi nochroot logfile=/var/log/mini_httpd/mini_httpd.log 適当にwebコンテンツを作ります。 /var/www/localhost/htdocs miniweb:~#vi index.cgi #!/bin/sh echo "Content-type: text/html" echo "" set miniweb:~# chmod +x index.cgi mini_httpdを起動サービスに登録します。 miniweb:~# rc-update add mini_httpd boot miniweb:~# rc-service mini_httpd start miniweb:~# reboot 以上。 どっかからcurlででも試してみてください。 host:~# apk add curl host:~# curl 172.17.0.2 ... (環境変数の一覧が出てきます) ... 補足 最後の curl で「httpdがあがってない」エラーが出るときは mini_httpd サービスが起動していません。 手動で起動してみてください。 host:~# docker exec -it miniweb /bin/ash miniweb:~# rc boot miniweb~#:rc-satus Runlevel: boot mini_httpd ... 'rc-service'や'rc-update'だと「もう起動してるよ」とエラーになります。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

FirebaseUIをビルドするための環境をDockerで作る

はじめに firebaseuiを多言語で使うには各言語用にビルドされたものが必要で、<script>タグでCDNから取得する場合は手間ではないんだけど、node環境などimportして使いたければ自前でビルドする必要があって面倒くさい。 https://github.com/firebase/firebaseui-web#developer-setup パッケージの更新や、日本語以外の対応が必要になった際に動きやすいよう、Dockerでfirebaseuiのビルド環境を作った。 なお、firebaseuiを日本語化する方法を解説した記事で、firebaseui-ja なるnpmパッケージを使っているのをちょくちょく見かけるけど、あれはFirebaseの公式パッケージではない。 2年前の初回登録以降メンテナンスはされていないようで、公式のfirebaseuiとはけっこうバージョンが離れている。 https://www.npmjs.com/package/firebaseui-ja Dockerfile FROM node:15-buster-slim WORKDIR /node RUN mkdir -p /usr/share/man/man1 RUN apt-get update \ && apt-get install -y git curl default-jdk RUN npm install -g n RUN n 8.17.0 RUN git clone --depth 1 https://github.com/firebase/firebaseui-web.git ポイント Docker環境を作る際に引っかかったポイントは次の2点。 最新のnode環境では、node-sass がビルドエラーになる firebaseui-webが依存しているgulp-sass:4.1.0が、node-sass:4.8.3に依存しており、最新のnode環境ではビルドできない。 node-sass のバージョンを上げるか、nodeのバージョンを下げる必要がある。 今回はnodeのバージョンを下げることで対応した。 node-sass:4.8.3 に対応させるためには、node 8 まで下げなければいけないらしい。 node8系の最終バージョンである8.17.0にダウングレードした。 RUN npm install -g n RUN n 8.17.0 [参考] https://qiita.com/ymasaoka/items/ab18c49a9074973ef75a jdkが必要 firebaseuiのビルド条件は次のように指定されている。 Node.js (>= 6.0.0) npm (should be included with Node.js) Java SE Runtime Environment 8 なので、default-jdk をインストールしようとしたのだけど、うまくいかない。 対応策を調べてみると、/usr/share/man/man1 というディレクトリを作成すると問題が回避できるらしいので、この処理をapt-getの前に行う。 RUN mkdir -p /usr/share/man/man1 RUN apt-get update \ && apt-get install -y git curl default-jdk [参考] https://qiita.com/SHinGo-Koba/items/a73e5f345c22c5ebbf96 ビルドする 環境が整えば、あとはマニュアル通りの手順でビルドできる。 npm install npm run build build-npm-ja ja の部分を好きな言語コードに変更すれば、各言語版ができる。 distディレクトリの中に、npm__ja.js が作成されているので、これをimportして使う。 typescript用の型定義index.d.tsも作られている。 # ls ./dist/ externs index.d.ts npm__ja.js import firebaseui from './npm__ja' できあがり!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

docker-compose buildしても、 error node-sass@6.0.0: The engine "node" is incompatible with this module. Expected version ">=12". Got "10.24.0"と言われる

はじめに 本記事は、まだ未解決のため、現段階まででわかっていることを書き示すのみとします [追記] 5/13 18時に解決しました [追記]解決策 コンテナ内で以下のコマンドを叩くことで解決しました npm rebuild node-sass エラーには正直に従えば良かったみたいです 発生した原因はもうちょっと深掘りしてきます! 起きていること ある朝、いつものようにdocker-compose up -d にてコンテナを起動してやると、、、、、 Found bindings for the following environments: webpacker_1 | - OS X 64-bit with Node.js 14.x webpacker_1 | webpacker_1 | This usually happens because your environment has changed since running `npm install`. webpacker_1 | Run `npm rebuild node-sass` to download the binding for your current environment. webpacker_1 | at module.exports (/soccer_app/node_modules/node-sass/lib/binding.js:15:13) webpacker_1 | at Object.<anonymous> (/soccer_app/node_modules/node-sass/lib/index.js:13:35) webpacker_1 | at Module._compile (internal/modules/cjs/loader.js:778:30) webpacker_1 | at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10) webpacker_1 | at Module.load (internal/modules/cjs/loader.js:653:32) webpacker_1 | at tryModuleLoad (internal/modules/cjs/loader.js:593:12) webpacker_1 | at Function.Module._load (internal/modules/cjs/loader.js:585:3) webpacker_1 | at Module.require (internal/modules/cjs/loader.js:692:17) webpacker_1 | at require (internal/modules/cjs/helpers.js:25:18) webpacker_1 | at getDefaultSassImpl (/soccer_app/node_modules/sass-loader/dist/index.js:198:10) マジで何もしてないのに、いきなり変わった!!!! と言いたいところですが、多分なんかしたんでしょう、、、、が、心当たりがない。 とりあえずエラー文を読んでみた Run `npm rebuild node-sass` to download the binding for your current environment. ふむふむ、npm rebuild node-sassしろと。 わかったよ、してやる!!ということでコマンドを叩くも1ミリの変化なし。 もう少し、エラー文を見てあげる webpacker_1 | Node Sass could not find a binding for your current environment: Linux 64-bit with Node.js 10.x webpacker_1 | webpacker_1 | Found bindings for the following environments: webpacker_1 | - OS X 64-bit with Node.js 14.x webpacker_1 | webpacker_1 | This usually happens because your environment has changed since running `npm install`. 直訳すると、 ・Sassは現在の環境のバインディングを見つけることができませんでした ・これは通常、 npminstallを実行してから環境が変更されたために発生します。 ん〜、よくわからんが、多分node関連で、なんかが変わっちゃった??? まあ、だったらとりあえず本質的解決にはならんが、コードは触ってないし最初からしちゃえということで docker system pruneで大掃除してからdocker-compose build!!!!!!とコマンドで叩く!!! そして私は青ざめる(笑) じゃーーーーーん % docker-compose build db uses an image, skipping chrome uses an image, skipping Building web [+] Building 47.7s (14/15) => [internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 549B 0.0s => [internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => [internal] load metadata for docker.io/library/ruby:2.6.5 0.9s => [ 1/11] FROM docker.io/library/ruby:2.6.5@sha256:651078e89471c30567685dce4caa321adf1f846b353e0 0.0s => [internal] load build context 2.9s => => transferring context: 2.85MB 2.9s => CACHED [ 2/11] RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - && ec 0.0s => CACHED [ 3/11] RUN apt-get update -qq && apt-get install -y build-essential libpq-dev nodejs y 0.0s => CACHED [ 4/11] WORKDIR /soccer_app 0.0s => CACHED [ 5/11] COPY Gemfile /soccer_app/Gemfile 0.0s => CACHED [ 6/11] COPY Gemfile.lock /soccer_app/Gemfile.lock 0.0s => CACHED [ 7/11] RUN gem install bundler 0.0s => CACHED [ 8/11] RUN bundle install 0.0s => [ 9/11] COPY . /soccer_app 21.5s => ERROR [10/11] RUN yarn install --check-files 22.2s ------ > [10/11] RUN yarn install --check-files: #14 1.525 yarn install v1.22.5 #14 1.695 [1/4] Resolving packages... #14 2.853 warning node-sass > node-gyp > request@2.88.2: request has been deprecated, see https://github.com/request/request/issues/3142 #14 2.979 [2/4] Fetching packages... #14 21.85 info fsevents@2.3.2: The platform "linux" is incompatible with this module. #14 21.85 info "fsevents@2.3.2" is an optional dependency and failed compatibility check. Excluding it from installation. #14 21.86 info fsevents@1.2.13: The platform "linux" is incompatible with this module. #14 21.86 info "fsevents@1.2.13" is an optional dependency and failed compatibility check. Excluding it from installation. #14 21.86 error node-sass@6.0.0: The engine "node" is incompatible with this module. Expected version ">=12". Got "10.24.0" #14 21.87 info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command. #14 21.87 error Found incompatible module. ------ executor failed running [/bin/sh -c yarn install --check-files]: exit code: 1 ERROR: Service 'web' failed to build まあ、正直この程度のエラーでは動じません! エラー文を見ていきましょう! node-sass@6.0.0: The engine "node" is incompatible with this module. Expected version ">=12". Got "10.24.0" このエラー文が全てな気がします。 おそらくnodeのバージョンが古いんだと! いろいろ調べてみるとこちらの記事に当たりました https://dev.classmethod.jp/articles/node-sass-could-not-find-a-binding/ ただ、私の場合はこれでは治らず。 そういえば、Dockerfileでバージョン指定してたっけかな〜〜と思いみる FROM ruby:2.6.5 RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - \ && echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list RUN apt-get update -qq && apt-get install -y build-essential libpq-dev nodejs yarn WORKDIR /soccer_app COPY Gemfile /soccer_app/Gemfile COPY Gemfile.lock /soccer_app/Gemfile.lock RUN gem install bundler RUN bundle install COPY . /soccer_app RUN yarn install --check-files RUN bundle exec rails webpacker:compile してない!!! じゃあバージョン指定してやればいな!!ローカルと同じにしてみよう FROM ruby:2.6.5 RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - \ && echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list RUN apt-get update -qq && apt-get install -y build-essential libpq-dev nodejs yarn RUN apt-get install -y nodejs npm && npm install n -g && n 14.17.0 WORKDIR /soccer_app COPY Gemfile /soccer_app/Gemfile COPY Gemfile.lock /soccer_app/Gemfile.lock RUN gem install bundler RUN bundle install COPY . /soccer_app RUN yarn install --check-files RUN bundle exec rails webpacker:compile おっけい!これで、エラー文がいうところは満たされたはず 勝利した顔でdocker-compose buildを叩いてみる => [11/12] RUN yarn install --check-files 35.9s => ERROR [12/12] RUN bundle exec rails webpacker:compile 24.2s ------ > [12/12] RUN bundle exec rails webpacker:compile: #17 6.945 Compiling... #17 24.08 Compilation failed: #17 24.08 Hash: 5b9cb701d467f386094d #17 24.08 Version: webpack 4.46.0 #17 24.08 Time: 14957ms #17 24.08 Built at: 05/13/2021 6:59:23 AM #17 24.08 19 assets #17 24.08 Entrypoint application = js/application-4af633c300cc707e06da.js js/application-4af633c300cc707e06da.js.map #17 24.08 Entrypoint chat_scroll = js/chat_scroll-9d46874ed4ab77b34f53.js js/chat_scroll-9d46874ed4ab77b34f53.js.map #17 24.08 Entrypoint count = js/count-59340b06f309e34c98c2.js js/count-59340b06f309e34c98c2.js.map #17 24.08 Entrypoint myphoto_preview = js/myphoto_preview-8324ca7303a9dcae160d.js js/myphoto_preview-8324ca7303a9dcae160d.js.map #17 24.08 Entrypoint navbar = js/navbar-31125c36983d5d8690af.js js/navbar-31125c36983d5d8690af.js.map #17 24.08 Entrypoint practice_preview = js/practice_preview-8bf72fefd5a23c861bc6.js js/practice_preview-8bf72fefd5a23c861bc6.js.map #17 24.08 Entrypoint ptag = js/ptag-c877989e2f581d065b0c.js js/ptag-c877989e2f581d065b0c.js.map #17 24.08 Entrypoint slider = js/slider-30f991808eb6fbf53e55.js js/slider-30f991808eb6fbf53e55.js.map #17 24.08 [108] ./app/javascript/packs/slider.js 231 bytes {0} {7} [built] #17 24.08 [109] (webpack)/buildin/module.js 552 bytes {0} [built] #17 24.08 [112] ./app/javascript/packs/application.js 872 bytes {0} [built] #17 24.08 [114] (webpack)/buildin/global.js 905 bytes {0} [built] #17 24.08 [115] ./app/javascript/stylesheets/application.scss 664 bytes {0} [built] #17 24.08 [117] ./node_modules/css-loader/dist/cjs.js??ref--7-1!./node_modules/postcss-loader/src??ref--7-2!./node_modules/sass-loader/dist/cjs.js??ref--7-3!./app/javascript/stylesheets/application.scss 322 bytes {0} [built] [failed] [1 error] #17 24.08 [120] ./app/javascript/channels/index.js 205 bytes {0} [built] #17 24.08 [121] ./app/javascript/channels sync _channel\.js$ 190 bytes {0} [built] #17 24.08 [122] ./app/javascript/packs/chat_scroll.js 155 bytes {1} [built] #17 24.08 [123] ./app/javascript/packs/count.js 449 bytes {2} [built] #17 24.08 [124] ./app/javascript/packs/myphoto_preview.js 694 bytes {3} [built] #17 24.08 [125] ./app/javascript/packs/navbar.js 1.39 KiB {4} [built] #17 24.08 [126] ./app/javascript/packs/practice_preview.js 919 bytes {5} [built] #17 24.08 [127] ./app/javascript/packs/ptag.js 1.71 KiB {6} [built] #17 24.08 [128] ./app/javascript/channels/chat_message_channel.js + 1 modules 1.39 KiB {0} [optional] [built] #17 24.08 | ./app/javascript/channels/chat_message_channel.js 1.13 KiB [optional] [built] #17 24.08 | ./app/javascript/channels/consumer.js 259 bytes [built] #17 24.08 + 114 hidden modules #17 24.08 #17 24.08 ERROR in ./app/javascript/stylesheets/application.scss (./node_modules/css-loader/dist/cjs.js??ref--7-1!./node_modules/postcss-loader/src??ref--7-2!./node_modules/sass-loader/dist/cjs.js??ref--7-3!./app/javascript/stylesheets/application.scss) #17 24.08 Module build failed (from ./node_modules/sass-loader/dist/cjs.js): #17 24.08 Error: Node Sass version 6.0.0 is incompatible with ^4.0.0. #17 24.08 at getRenderFuncFromSassImpl (/soccer_app/node_modules/sass-loader/dist/index.js:165:13) #17 24.08 at Object.loader (/soccer_app/node_modules/sass-loader/dist/index.js:79:18) #17 24.08 @ ./app/javascript/stylesheets/application.scss 2:26-228 #17 24.08 @ ./app/javascript/packs/application.js #17 24.08 ------ executor failed running [/bin/sh -c bundle exec rails webpacker:compile]: exit code: 1 ERROR: Service 'web' failed to build 汗汗汗、、、、 でもちょっと変わった!コマンドが1つ分進んでいる!一歩前進!やれるかわからないけど、やってみる精神突き進む!! とはいえ、ごめん!!全然わからない!Google先生! と、こちらの記事に遭遇 https://hapicode.com/css/sass-loader-error.html#%E8%A7%A3%E6%B1%BA%E7%AD%96-2-node-module-%E5%89%8A%E9%99%A4%E3%81%97%E3%81%A6%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB 以下のコマンドを叩いてみる % npm uninstall node-sass % npm install node-sass@4 再度,docker-compose buildを実行!!!!!! tochikawa@tochinoMacBook-Pro soccer_app % docker-compose build db uses an image, skipping chrome uses an image, skipping Building web [+] Building 98.8s (18/18) FINISHED => [internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 37B 0.0s => [internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => [internal] load metadata for docker.io/library/ruby:2.6.5 1.8s => [auth] library/ruby:pull token for registry-1.docker.io 0.0s => [internal] load build context 5.4s => => transferring context: 125.23MB 5.3s => [ 1/12] FROM docker.io/library/ruby:2.6.5@sha256:651078e89471c30567685dce4caa321adf1f846b353e0 0.0s => CACHED [ 2/12] RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - && ec 0.0s => CACHED [ 3/12] RUN apt-get update -qq && apt-get install -y build-essential libpq-dev nodejs y 0.0s => CACHED [ 4/12] RUN apt-get install -y nodejs npm && npm install n -g && n 14.17.0 0.0s => CACHED [ 5/12] WORKDIR /soccer_app 0.0s => CACHED [ 6/12] COPY Gemfile /soccer_app/Gemfile 0.0s => CACHED [ 7/12] COPY Gemfile.lock /soccer_app/Gemfile.lock 0.0s => CACHED [ 8/12] RUN gem install bundler 0.0s => CACHED [ 9/12] RUN bundle install 0.0s => [10/12] COPY . /soccer_app 21.0s => [11/12] RUN yarn install --check-files 33.5s => [12/12] RUN bundle exec rails webpacker:compile 4.7s => exporting to image 32.2s => => exporting layers 32.2s => => writing image sha256:d65afdd816d7f8e9ec98c4274f6c495e3945be7349a06caca0bc5a3b83db81e0 0.0s => => naming to docker.io/library/soccer_app_web 0.0s Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them Successfully built d65afdd816d7f8e9ec98c4274f6c495e3945be7349a06caca0bc5a3b83db81e0 Building webpacker [+] Building 4.3s (17/17) FINISHED => [internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 37B 0.0s => [internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => [internal] load metadata for docker.io/library/ruby:2.6.5 0.9s => [ 1/12] FROM docker.io/library/ruby:2.6.5@sha256:651078e89471c30567685dce4caa321adf1f846b353e0 0.0s => [internal] load build context 3.2s => => transferring context: 2.78MB 3.1s => CACHED [ 2/12] RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - && ec 0.0s => CACHED [ 3/12] RUN apt-get update -qq && apt-get install -y build-essential libpq-dev nodejs y 0.0s => CACHED [ 4/12] RUN apt-get install -y nodejs npm && npm install n -g && n 14.17.0 0.0s => CACHED [ 5/12] WORKDIR /soccer_app 0.0s => CACHED [ 6/12] COPY Gemfile /soccer_app/Gemfile 0.0s => CACHED [ 7/12] COPY Gemfile.lock /soccer_app/Gemfile.lock 0.0s => CACHED [ 8/12] RUN gem install bundler 0.0s => CACHED [ 9/12] RUN bundle install 0.0s => CACHED [10/12] COPY . /soccer_app 0.0s => CACHED [11/12] RUN yarn install --check-files 0.0s => CACHED [12/12] RUN bundle exec rails webpacker:compile 0.0s => exporting to image 0.0s => => exporting layers 0.0s => => writing image sha256:d65afdd816d7f8e9ec98c4274f6c495e3945be7349a06caca0bc5a3b83db81e0 0.0s => => naming to docker.io/library/soccer_app_webpacker 0.0s Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them Successfully built d65afdd816d7f8e9ec98c4274f6c495e3945be7349a06caca0bc5a3b83db81e0 Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them コマンドは通るように!!!!!よし!!!! この勢いで、docker-compose up してやる!!! はい!!!ぽち!(このとき、次回、城之内死す!をなぜか思い出しました) webpacker_1 | ERROR in ./app/javascript/stylesheets/application.scss (./node_modules/css-loader/dist/cjs.js??ref--7-1!./node_modules/postcss-loader/src??ref--7-2!./node_modules/sass-loader/dist/cjs.js??ref--7-3!./app/javascript/stylesheets/application.scss) webpacker_1 | Module build failed (from ./node_modules/sass-loader/dist/cjs.js): webpacker_1 | Error: Missing binding /soccer_app/node_modules/node-sass/vendor/linux-x64-83/binding.node webpacker_1 | Node Sass could not find a binding for your current environment: Linux 64-bit with Node.js 14.x webpacker_1 | webpacker_1 | Found bindings for the following environments: webpacker_1 | - OS X 64-bit with Node.js 14.x webpacker_1 | webpacker_1 | This usually happens because your environment has changed since running `npm install`. webpacker_1 | Run `npm rebuild node-sass` to download the binding for your current environment. webpacker_1 | at module.exports (/soccer_app/node_modules/node-sass/lib/binding.js:15:13) webpacker_1 | at Object.<anonymous> (/soccer_app/node_modules/node-sass/lib/index.js:14:35) webpacker_1 | at Module._compile (internal/modules/cjs/loader.js:1068:30) webpacker_1 | at Object.Module._extensions..js (internal/modules/cjs/loader.js:1097:10) webpacker_1 | at Module.load (internal/modules/cjs/loader.js:933:32) webpacker_1 | at Function.Module._load (internal/modules/cjs/loader.js:774:14) webpacker_1 | at Module.require (internal/modules/cjs/loader.js:957:19) webpacker_1 | at require (internal/modules/cjs/helpers.js:88:18) webpacker_1 | at getDefaultSassImpl (/soccer_app/node_modules/sass-loader/dist/index.js:198:10) webpacker_1 | at Object.loader (/soccer_app/node_modules/sass-loader/dist/index.js:80:29) やっぱりだめ、、、ん〜〜〜〜〜 もう少し細かく見ていく必要がありますね おわりに 結局未解決で申し訳ないです。 引き続き、エラー解消に努めます
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Docker Alpineコンテナを利用したSSHサーバーの構築

はじめに 最終的にはKubernetesでの利用を考えているrsyncバックアップ用のサーバーを構築するために、AlpineコンテナでSSHサーバーを稼動するテストを行ないました。 その際に、パスワード認証はできるものの、公開鍵を利用したログインができなかったため事象が発生しました。 Ubuntuベースで作成したプロトタイプを元にしていますが、Alpineに移行したのでそのDockerfileなどをメモしておくことにしました。 参考資料 https://stackoverflow.com/questions/61833713/how-to-login-by-ssh-in-alpine-linux-without-passwords コンテナの構築 Dockerファイルはだいたい次のような内容になっています。 Alpineイメージで/etc/init.d/のスクリプトを起動させるには、openrcパッケージを利用しますが、今回は直接起動するためインストールしていません。 Dockerfile FROM alpine:3.13.5 RUN apk --no-cache add tzdata bash ca-certificates make openssh rsync openssl ENV SSHD_CONFIG_FILEPATH /etc/ssh/sshd_config ENV SSH_PUBKEY_FILEPATH /conf/id_key.pub ENV SSH_AUTHKEYS_FILEPATH /root/.ssh/authorized_keys COPY run.sh /run.sh RUN chmod +x /run.sh EXPOSE 22 ENTRYPOINT ["/run.sh"] 最後に呼んでいるrun.shの中では次のような操作を行なっています。 run.sh #!/bin/bash -x SSHD_CONFIG_FILEPATH="${SSHD_CONFIG_FILEPATH:-/etc/ssh/sshd_config}" SSH_SERVERKEYS_FILEPATH="${SSH_SERVERKEYS_FILEPATH_LIST:-/etc/ssh/ssh_host_rsa_key}" ## update the sshd_config file echo "HostKey ${SSH_SERVERKEYS_FILEPATH}" >> "${SSHD_CONFIG_FILEPATH}" echo "PubkeyAuthentication yes" >> "${SSHD_CONFIG_FILEPATH}" echo "PasswordAuthentication no" >> "${SSHD_CONFIG_FILEPATH}" echo "PermitRootLogin yes" >> "${SSHD_CONFIG_FILEPATH}" echo "StrictModes yes" >> "${SSHD_CONFIG_FILEPATH}" ## prepare the ~/.ssh/authorized_keys SSH_PUBKEY_FILEPATH="${SSH_PUBKEY_FILEPATH:-/conf/id_key.pub}" SSH_AUTHKEYS_FILEPATH="${SSH_AUTHKEYS_FILEPATH:-/root/.ssh/authorized_keys}" SSH_AUTHKEYS_BASEDIR="$(dirname ${SSH_AUTHKEYS_FILEPATH})" mkdir -p "${SSH_AUTHKEYS_BASEDIR}" chmod 700 "${SSH_AUTHKEYS_BASEDIR}" cp "${SSH_PUBKEY_FILEPATH}" "${SSH_AUTHKEYS_FILEPATH}" chmod 0600 "${ROOK_SSH_AUTHKEYS_FILEPATH}" ## change the root password echo "root:$(openssl rand -hex 12)" | chpasswd exec /usr/sbin/sshd -D 次に必要な秘密鍵・公開鍵を準備します。 ssh-keygenの利用 $ ssh-keygen -t ed25519 -f id_ed25519 $ ssh-keygen -t ed25519 -f ssh_host_ed25519_key 最終的に次のようなファイルを準備したことになります。 $ ls Dockerfile id_ed25519 id_ed25519.pub run.sh ssh_host_ed25519_key ssh_host_ed25519_key.pub Dockerコンテナのビルドと実行 準備したファイルを利用してDockerコンテナをビルドし、再現するかテストを行ないます。 buildとrun $ sudo docker build . --tag sshd $ sudo docker run -it --rm -v `pwd`/id_ed25519.pub:/conf/id_key.pub \ -v `pwd`/ssh_host_ed25519_key:/etc/ssh/ssh_host_rsa_key \ -p 2222:22 --name sshd sshd:latest 既存のsshdと競合しないように、2222番ポートを利用しています。環境に応じて変更してください。 無事に起動したら別のshellから接続を試みます。 あらかじめid_ed25519ファイルのあるディレクトリに移動してから進めます。 sshコマンドによる接続テスト $ ls Dockerfile id_ed25519 id_ed25519.pub run.sh ssh_host_ed25519_key ssh_host_ed25519_key.pub $ ssh -i id_ed25519 -p 2222 root@localhost エラーの原因について 遭遇したエラーについてまとめておきます。 エラーメッセージ 次のようなエラーメッセージが表示されています。 ログイン失敗時のログ ssh -i conf/id_ed25519 -p 2222 root@localhost root@localhost: Permission denied (publickey,keyboard-interactive). 次のようなメッセージが表示されるかもしれません。 ssh -i conf/id_ed25519 -p 2222 root@localhost Received disconnect from 127.0.0.1 port 2222:2: Too many authentication failures Disconnected from 127.0.0.1 port 2222 エラー発生の可能性と原因 このような事象が発生しているのには、いつくかの理由が考えられます。 接続しようとしているユーザーID(root)にパスワードが設定されていない sshコマンドがpublickey認証に対応していない 前者はrun.shの中で強制的にランダムなパスワードを実行時に指定するようになっています。 後者の原因は、/etc/ssh/ssh_configや~/.ssh/ssh_configに、PreferredAuthentications passwordのような設定を入れている場合に発生します。 Dockerコンテナ側の/etc/passwdで該当ユーザーのログイン・シェルが設定されている必要もあります。 alpineの場合、ユーザーIDをadduserコマンドでDockerfileで作成しただけでは、ログイン・シェルが/sbin/nologinなどに設定されていまいます。 一般ユーザーを追加する際の考慮点 chshコマンドはshadowパッケージから導入できますが、非対話的に設定することができないようなので、次のように一般ユーザーを作成しています。 test01ユーザーを作成する例 RUN adduser -S test01 && echo "test01:secret-password" | chpasswd RUN sed -i -e '/test01/s/sbin\/nologin/bin\/bash/' /etc/passwd 一応chpasswdコマンドを実行していますが、実際にはrootユーザーと同様に実行時にランダムなパスワードを設定する方法がお勧めです。 また、sedコマンドはbusybox版なので、デリミタに'/'文字以外を指定することはできません。 以上
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

dockerでsymfony & mysql & phpmyAdminのローカル開発環境を作る。②

前のページの続きになります。 前回の記事はこちら。 migrateできるようにする。 前回までで、ルーティングとtwigテンプレートの導入までは正常に動いていましたが、 教科書(Symfony4入門 掌田 津耶乃著)を読み進めていたところ、DBにマイグレーションするところでエラーになりました。 なぜか、postgresに接続しようとしている。 そんなことをdocker-composeに書いた覚えはないのに・・ そこで、以下のファイルを修正 /app/my_app/.env (symfonyのプロジェクトルートにある方の.env 前回のdocker用.envとは違う) DATABASE_URL= の後に、docker-compose.yamlのDATABASE_URLの値をコピペする。 mysql以外のドライバはコメントアウトする。 /app/my_app/.env # DATABASE_URL="sqlite:///%kernel.project_dir%/var/data.db" #DATABASE_URL="postgresql://db_user:db_password@127.0.0.1:5432/db_name?serverVersion=13&charset=utf8" #DATABASE_URL="mysql://db_user:db_password@127.0.0.1:3306/?serverVersion=5.7" DATABASE_URL="mysql://root:root@mysql/app_db" ここまででもう一度マイグレーションしてみると今度は以下のエラーが出ました。 docker-syncしてるからローカルホストから起動すると思っていたのですが、 php bin/console make:migrationはコンテナの中で実行しないとこういうエラーになるそうです。 なのでコンテナに入ります。 docker-compose exec app bash 入ったら、 cd my_app docker-compose exec app bash これで動きました。 以上 お疲れ様でした。 参考 Laravel+dockerの記事を参考にしましたが、symfonyでも同じように解決できました。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Nginxでドメイン名によってアクセスを振り分けてみた

はじめに 以下記事をほぼほぼ参考に試してみた備忘録です。 https://qiita.com/South_/items/7bdb1f373410cb1c907b jwilder/nginx-proxy っていうimageのnginxをプロキシとして使うとヘッダーで設定したホスト名でアクセスを割り振ってくれる。 ディレクトリ構成 $ tree . ├── docker-compose.yml ├── web │ └── index.html ├── web2 │ └── index.html └── web3 └── index.html docker-compose.yml $ cat docker-compose.yml version: '3' services: nginx-proxy: image: jwilder/nginx-proxy ports: - 80:80 volumes: - /var/run/docker.sock:/tmp/docker.sock:ro web: image: nginx environment: - VIRTUAL_HOST=web.localhost volumes: - ./web:/usr/share/nginx/html web2: image: nginx environment: - VIRTUAL_HOST=web2.localhost volumes: - ./web2:/usr/share/nginx/html web3: image: nginx environment: - VIRTUAL_HOST=web3.localhost volumes: - ./web3:/usr/share/nginx/html htmlファイルを用意 webコンテナ <html> <head> <meta charset="utf-8"/> <meta name="viewport" content="width=device-width, initial-scale=1"/> <title>webコンテナのページ</title> </head> <body> <h1>webコンテナのページ</h1> </body> </html> web2コンテナ <html> <head> <meta charset="utf-8"/> <meta name="viewport" content="width=device-width, initial-scale=1"/> <title>web2コンテナのページ</title> </head> <body> <h1>web2コンテナのページ</h1> </body> </html> web3コンテナ <html> <head> <meta charset="utf-8"/> <meta name="viewport" content="width=device-width, initial-scale=1"/> <title>web3コンテナのページ</title> </head> <body> <h1>web3コンテナのページ</h1> </body> </html> docker-compose実行 $ docker-compose up -d Creating nginx_reverse_proxy_as_multidomainserver_web_1 ... done Creating nginx_reverse_proxy_as_multidomainserver_web3_1 ... done Creating nginx_reverse_proxy_as_multidomainserver_web2_1 ... done Creating nginx_reverse_proxy_as_multidomainserver_nginx-proxy_1 ... done 動作検証 $ curl -H 'Host:web.localhost' 0.0.0.0 <!DOCTYPE html> <html> <head> <meta charset="utf-8"/> <meta name="viewport" content="width=device-width, initial-scale=1"/> <title>webコンテナのページ</title> </head> <body> <h1>webコンテナのページ</h1> </body> </html> $ curl -H 'Host:web2.localhost' 0.0.0.0 <!DOCTYPE html> <html> <head> <meta charset="utf-8"/> <meta name="viewport" content="width=device-width, initial-scale=1"/> <title>web2コンテナのページ</title> </head> <body> <h1>web2コンテナのページ</h1> </body> </html> $ curl -H 'Host:web3.localhost' 0.0.0.0 <!DOCTYPE html> <html> <head> <meta charset="utf-8"/> <meta name="viewport" content="width=device-width, initial-scale=1"/> <title>web3コンテナのページ</title> </head> <body> <h1>web3コンテナのページ</h1> </body> </html>
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

NginxでURL振り分けをしてみた

はじめに 以下の記事をほぼほぼ参考に試してみた備忘録です。 https://qiita.com/zawawahoge/items/d58ab6b746625e8d4457 ディレクトリ構成 $ tree nginx_to_sort/ nginx_to_sort/ ├── cat-server │ └── index.html ├── docker-compose.yml ├── dog-server │ └── index.html └── reverse-proxy └── nginx.conf docker-compose.ymlを準備 $ cat docker-compose.yml version: '3' services: dog-server: image: nginx container_name: 'dog-container' volumes: - ./dog-server:/usr/share/nginx/html ports: - 7000:80 cat-server: image: nginx container_name: 'cat-container' volumes: - ./cat-server:/usr/share/nginx/html ports: - 7001:80 reverse-proxy: image: nginx volumes: - ./reverse-proxy/nginx.conf:/etc/nginx/nginx.conf ports: - 80:80 nginx.confを準備 $ cat reverse-proxy/nginx.conf events { worker_connections 16; } http { server { listen 80; server_name localhost; location /dog { proxy_pass http://host.docker.internal:7000/; proxy_redirect off; } location /cat { proxy_pass http://host.docker.internal:7001/; proxy_redirect off; } } } dogサーバー・catサーバーにhtmlファイル配置 $ cat dog-server/index.html <!DOCTYPE html> <html> <head> <meta charset="utf-8"/> <meta name="viewport" content="width=device-width, initial-scale=1"/> <title>犬好きのためのページ</title> </head> <body> <h1>犬好きのためのページ</h1> </body> </html> $ cat cat-server/index.html <!DOCTYPE html> <html> <head> <meta charset="utf-8"/> <meta name="viewport" content="width=device-width, initial-scale=1"/> <title>猫好きのためのページ</title> </head> <body> <h1>猫好きのためのページ</h1> </body> </html> docker-compose実行 $ docker-compose up -d Creating network "nginx_reverse_proxy_as_loadbarancer_default" with the default driver Creating nginx_reverse_proxy_as_loadbarancer_reverse-proxy_1 ... done Creating cat-container ... done Creating dog-container ... done 動作検証 $ curl --verbose localhost/dog -p 80 * Trying ::1... * TCP_NODELAY set * Connected to localhost (::1) port 80 (#0) > GET /dog HTTP/1.1 > Host: localhost > User-Agent: curl/7.64.1 > Accept: */* > < HTTP/1.1 200 OK < Server: nginx/1.19.10 < Date: Wed, 12 May 2021 15:21:26 GMT < Content-Type: text/html < Content-Length: 264 < Connection: keep-alive < Last-Modified: Sat, 08 May 2021 05:38:52 GMT < ETag: "609623ec-108" < Accept-Ranges: bytes < <!DOCTYPE html> <html> <head> <meta charset="utf-8"/> <meta name="viewport" content="width=device-width, initial-scale=1"/> <title>犬好きのためのページ</title> </head> <body> <h1>犬好きのためのページ</h1> </body> * Connection #0 to host localhost left intact </html>* Trying 0.0.0.80... * TCP_NODELAY set * Immediate connect fail for 0.0.0.80: No route to host * Closing connection 1 curl: (7) Couldn't connect to server * Closing connection 0 $ curl --verbose localhost/cat -p 80 * Trying ::1... * TCP_NODELAY set * Connected to localhost (::1) port 80 (#0) > GET /cat HTTP/1.1 > Host: localhost > User-Agent: curl/7.64.1 > Accept: */* > < HTTP/1.1 200 OK < Server: nginx/1.19.10 < Date: Wed, 12 May 2021 15:22:20 GMT < Content-Type: text/html < Content-Length: 264 < Connection: keep-alive < Last-Modified: Sat, 08 May 2021 05:39:57 GMT < ETag: "6096242d-108" < Accept-Ranges: bytes < <!DOCTYPE html> <html> <head> <meta charset="utf-8"/> <meta name="viewport" content="width=device-width, initial-scale=1"/> <title>猫好きのためのページ</title> </head> <body> <h1>猫好きのためのページ</h1> </body> * Connection #0 to host localhost left intact </html>* Trying 0.0.0.80... * TCP_NODELAY set * Immediate connect fail for 0.0.0.80: No route to host * Closing connection 1 curl: (7) Couldn't connect to server * Closing connection 0
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Nginxをリバースプロキシとして使ってみた

はじめに 以下の記事を参考に試してみた結果の備忘録です。 https://qiita.com/OPySPGcLYpJE0Tc/items/1f4219a51980a75696b5 リバースプロキシサーバーの構築 centos7のdockerコンテナを用意 $ docker run -it -d --privileged --name nginx_reverse_proxy centos:centos7 /sbin/init コンテナにnginxをインストール コンテナにログイン $ docker exec -it nginx_reverse_proxy /bin/bash nginxをインストール # vi /etc/yum.repos.d/nginx.repo [nginx] name=nginx repo baseurl=http://nginx.org/packages/centos/7/$basearch/ gpgcheck=0 enabled=1 # yum -y install nginx nginxを起動する # systemctl start nginx # systemctl status nginx ● nginx.service - nginx - high performance web server Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; vendor preset: disabled) Active: active (running) since Wed 2021-05-12 14:33:11 UTC; 7s ago Docs: http://nginx.org/en/docs/ Process: 168 ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf (code=exited, status=0/SUCCESS) Main PID: 169 (nginx) CGroup: /docker/ef5c700de13cd3382f585be627278ab4d2bf5263b9867a2d9a3d5e431247512b/system.slice/nginx.service ├─169 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx... ├─170 nginx: worker process └─171 nginx: worker process ‣ 169 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx... May 12 14:33:11 ef5c700de13c systemd[1]: Starting nginx - high performanc.... May 12 14:33:11 ef5c700de13c systemd[1]: Started nginx - high performance.... Hint: Some lines were ellipsized, use -l to show in full. # curl localhost:80 // nginxのデフォルトのhtmlテンプレートが表示される。省略。 nginxをリバースプロキシとして設定 リバースプロキシとしての設定ファイルを以下のように追加。 ※なお最初の3行でキャッシュ機能を有効化させている点も注意すること。 # hostname -i 172.17.0.2 # vi /etc/nginx/conf.d/backend.conf proxy_cache_path /var/cache/nginx/rproxy keys_zone=zone1:1m max_size=1g inactive=24h; proxy_temp_path /var/cache/nginx_tmp; proxy_ignore_headers Cache-Control; server { listen 80; server_name 172.17.0.2; location / { proxy_pass http://172.17.0.3:8080; proxy_cache zone1; proxy_cache_valid 200 302 600s; add_header X-Nginx-Cache $upstream_cache_status; } } nginxを再起動 # systemctl restart nginx webサーバーの構築 centos7のdockerコンテナを用意 $ docker run -it -d --privileged --name httpd_server centos:centos7 /sbin/init コンテナにhttpdをインストール dockerコンテナログイン $ docker exec -it httpd_server /bin/bash httpdをインストール # yum -y install httpd httpdをwebサーバとして設定 8080番ポートに設定。(リバースプロキシnginxのコンテナからアクセスされるようにするため) # vi /etc/httpd/conf/httpd.conf Listen 8080 httpd起動 # systemctl start httpd # systemctl status httpd lsofコマンドで確認 # yum -y install lsof # lsof -i:8080 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME httpd 171 root 3u IPv4 697190 0t0 TCP *:webcache (LISTEN) httpd 172 apache 3u IPv4 697190 0t0 TCP *:webcache (LISTEN) httpd 173 apache 3u IPv4 697190 0t0 TCP *:webcache (LISTEN) httpd 174 apache 3u IPv4 697190 0t0 TCP *:webcache (LISTEN) httpd 175 apache 3u IPv4 697190 0t0 TCP *:webcache (LISTEN) httpd 176 apache 3u IPv4 697190 0t0 TCP *:webcache (LISTEN) webページを配置 # echo "hoge" > /var/www/html/index.html # curl localhost:8080 hoge 動作検証 キャッシュ確認 リバースプロキシへアクセスする前に、nginxの設定ファイルで記述したキャッシュ先ファイルを確認しておく。 空である。 # ls /var/cache/nginx/rproxy/ リバースプロキシへアクセス リバースプロキシへアクセスしてみる。 # curl 172.17.0.2:80 hoge キャッシュ確認 # ls /var/cache/nginx/rproxy/ bea87927112d3594daed0e660e1256e4 # cat /var/cache/nginx/rproxy/bea87927112d3594daed0e660e1256e4 m�`~�`�`pA)np"5-5c223261fc200" KEY: http://172.17.0.3:8080/ HTTP/1.1 200 OK Date: Wed, 12 May 2021 14:54:13 GMT Server: Apache/2.4.6 (CentOS) Last-Modified: Wed, 12 May 2021 14:51:42 GMT ETag: "5-5c223261fc200" Accept-Ranges: bytes Content-Length: 5 Connection: close Content-Type: text/html; charset=UTF-8 hoge アクセスログも確認 webサーバー側(httpd入れた側)のログを確認する。 最初にlocalhostでアクセスしたログと、リバースプロキシを介してアクセスしたログの2つがある。 # tail -f /var/log/httpd/access_log 127.0.0.1 - - [12/May/2021:14:52:17 +0000] "GET / HTTP/1.1" 200 5 "-" "curl/7.29.0" 172.17.0.2 - - [12/May/2021:14:54:13 +0000] "GET / HTTP/1.0" 200 5 "-" "curl/7.29.0" キャッシュが使われていることを確認する 上記のtailコマンド実行した状態で、以下のように2度、3度とリバースプロキシにアクセスしてみる。 # curl 172.17.0.2:80 hoge # curl 172.17.0.2:80 hoge 上記のようにアクセスしても、tailコマンドの反応はない。 つまり、webサーバーにアクセスされていない。 要するにキャッシュが使われていることが考えられる。 確認のためリバースプロキシ側(nginx)のログをみる。 以下のように4つログがあるので、リバースプロキシへはアクセスは行っている。 # cat /var/log/nginx/access.log 127.0.0.1 - - [12/May/2021:14:35:54 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-" 172.17.0.2 - - [12/May/2021:14:54:13 +0000] "GET / HTTP/1.1" 200 5 "-" "curl/7.29.0" "-" 172.17.0.2 - - [12/May/2021:15:00:57 +0000] "GET / HTTP/1.1" 200 5 "-" "curl/7.29.0" "-" 172.17.0.2 - - [12/May/2021:15:00:58 +0000] "GET / HTTP/1.1" 200 5 "-" "curl/7.29.0" "-" 以上から、2回目、3回目のリバースプロキシへのアクセスは、リバースプロキシへは届いているが、webサーバーへはアクセスされていないため、リバースプロキシ内のキャッシュが使われているはずであることがわかる。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む