nginx に関する投稿を表示しています

docker-compose で LDAP 認証のリバースプロキシを設定する

色々が色々あって、社内限定ツールに Active Directory を参照した LDAP 認証を掛けることがある。
それ自体は別にいいのだが Docker を使ってペペッと作って展開するといったときがやや面倒になった。

ので、それを docker-compose を使ってリバースプロキシを作ったら解決できたよ、というメモ。

 

こんな感じで docker-compose.yml を作って。

version: "2"

services:
  application:
    container_name: "${APP_NAME}_application"
    build: ./docker-app
    volumes:
      - ./src:/var/www/html
  proxy:
    container_name: "${APP_NAME}_proxy"
    build: ./docker-proxy
    ports:
      - "${HTTP_PORT}:80"
    links:
      - application:application

docker-compose をやったことがある人はご存知と思うが、このときの ${APP_NAME} や ${HTTP_PORT} は環境変数を指していて .env ファイルなどを作り APP_NAME=hogehoge みたいなことをしたらいい。

余談なのだけど、ドキュメントみたら version 3 のフォーマットがいつの間にかリリースされていて(しらなかった!!)、そっちに移行していく流れのほうがいいよねって思った。
Compose file version 3 reference | Docker Documentation

 

こんな感じで ./docker-proxy/Dockerfile を作って。

FROM httpd:alpine
COPY ./httpd.conf /usr/local/apache2/conf/httpd.conf

 

こんな感じで ./docker-proxy/httpd.conf を作って。

# default configures
ServerRoot "/usr/local/apache2"
Listen 80
LoadModule authn_file_module modules/mod_authn_file.so
LoadModule authn_core_module modules/mod_authn_core.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule authz_core_module modules/mod_authz_core.so
LoadModule access_compat_module modules/mod_access_compat.so
LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule reqtimeout_module modules/mod_reqtimeout.so
LoadModule filter_module modules/mod_filter.so
LoadModule mime_module modules/mod_mime.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule env_module modules/mod_env.so
LoadModule headers_module modules/mod_headers.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule version_module modules/mod_version.so
LoadModule unixd_module modules/mod_unixd.so
LoadModule status_module modules/mod_status.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule dir_module modules/mod_dir.so
LoadModule alias_module modules/mod_alias.so

<IfModule unixd_module>
    User daemon
    Group daemon
</IfModule>

ServerAdmin you@example.com
ServerName localhost:80

<Directory />
    AllowOverride none
    Require all denied
</Directory>

DocumentRoot "/usr/local/apache2/htdocs"

<Files ".ht*">
    Require all denied
</Files>

ErrorLog /proc/self/fd/2
LogLevel warn

<IfModule log_config_module>
    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
    LogFormat "%h %l %u %t \"%r\" %>s %b" common
    <IfModule logio_module>
      LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio
    </IfModule>
    CustomLog /proc/self/fd/1 common
</IfModule>

<IfModule mime_module>
    TypesConfig conf/mime.types
    AddType application/x-compress .Z
    AddType application/x-gzip .gz .tgz
</IfModule>

<IfModule ssl_module>
    SSLRandomSeed startup builtin
    SSLRandomSeed connect builtin
</IfModule>



# Load modules
LoadModule authn_core_module modules/mod_authn_core.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule authz_core_module modules/mod_authz_core.so
LoadModule auth_basic_module modules/mod_auth_basic.so

LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
LoadModule ldap_module modules/mod_ldap.so

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_wstunnel_module modules/mod_proxy_wstunnel.so


# LDAP
LDAPTrustedMode SSL
LDAPVerifyServerCert off


# Proxy
<VirtualHost *:80>
    ProxyRequests Off
    ProxyPreserveHost Off
    AllowEncodedSlashes On
    KeepAlive Off

    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>

    <Location />
        AuthName "Basic Auth"
        AuthType Basic
        AuthBasicProvider ldap
        AuthLDAPURL [ここにLDAPを参照するのURI]
        Require valid-user
    </Location>

    RequestHeader unset Authorization

    ProxyPass / http://application/
    ProxyPassReverse / http://application/
</VirtualHost>

 

あとは docker-compose up -d --build などと実行したら出来上がる。

$ docker-compose up -d --build

 

Apache をつかっている理由としては nginx の場合は公式イメージの中で LDAP のモジュールが提供されていないこと、組み込む場合にビルドが必要なことがあげられる。 Apache のイメージであればデフォルトで LDAP のモジュールが提供されている。さらに言えば
alpine イメージでも提供されているので debian ベースなイメージなどと比べて、軽量で高速上げ下げ出来たりしてめっちゃ良いよねってところもあった。調べると debian ベースにビルドしてるものもあって、良いんだけどう~~ん。

まあ「docker nginx ldap proxy」とか普通のワードで調べたらイメージだったり Dockerfile だったりが出てくるので、そのあたりを使ってもよかったのかもしれない。

debian ベースで nginx 1.11.13 をビルドする。 PR したらマージされる感あるのでバージョンアップもやっていけそう。
h3nrik/nginx-ldap - Docker Hub

debian ベースで nginx 1.9.9 をビルドする。2 年前から更新されていないので今後も更新されなさそう感
confirm/docker-nginx-ldap: nginx Docker image with ldap support

nginx 公式なのだけど nginx で LDAP ではなく、横にいる LDAP してくれるやつがよろしくやる、というものでちょっと違うかも。
nginxinc/nginx-ldap-auth: Example of LDAP authentication using ngx_http_auth_request_module

あるいは nginx-proxy っていうめっちゃ便利なリバースプロキシできる君があるので、これをベースに LDAP 認証のモジュールを追加するっていうのが、お手軽楽ちんで一番いいかもしれない。
jwilder/nginx-proxy: Automated nginx proxy for Docker containers using docker-gen

 

とりあえず一旦のところは Apache でやったよっていう話と、 nginx でも調べたら出てくるよ、ってまとめでおわり。

NGINX Unit なるものリリースされたらしいのでとりあえず PHP でも動かしてみる

NGINX Unit なるものがリリースされたらしい。

・NGINX 公式サイトの情報
NGINX Unit

・NGINX Unit 公式サイト
NGINX Unit

・見かけた記事
NGINXからアプリケーションサーバ「NGINX Unit」がオープンソースで登場。PHP、Go、Pythonに対応。Java、Node.jsにも対応予定 - Publickey

ドキュメントに書かれているインストール方法や設定を見てたらパッと出来そうだったので思いたってやったったの巻。

どうにも公式サイトのドキュメンテーションを見ると CentOS と Ubuntu 向けにはパッケージが適当されているっぽい。なのでコレを利用する。また nginx が既にいる環境でやると便利そうなので docker で立ち上げていく

// ホストにて
$ docker run --name nginx-unit -d -p 8080:80 nginx
$ docker exec -it nginx-unit bash

// 以降はコンテナ内、ゲストで作業

// 準備
# apt-get update
# apt-get install curl net-tools vim less

// キーの登録
# curl http://nginx.org/keys/nginx_signing.key > /tmp/nginx_signing.key
# apt-key add /tmp/nginx_signing.key

// /etc/apt/sources.list に追記
# vim /etc/apt/sources.list
deb http://nginx.org/packages/mainline/ubuntu/ xenial nginx
deb-src http://nginx.org/packages/mainline/ubuntu/ xenial nginx

// nginx-unit のインストール
# apt-get update
# apt-get install unit


// コンフィグ確認
# cat /etc/init.d/unit
CONFIG=/etc/unit/config

// /var/run/control.unit.sock が設定用のソケットファイルっぽい
    dumpconfig)
        curl -sS --unix-socket /var/run/control.unit.sock localhost >${CONFIG}.new



# vim /etc/unit/config
{
     "listeners": {
         "*:8300": {
             "application": "myapp"
         }
     },
     "applications": {
         "myapp": {
              "type": "php",
              "workers": 3,
              "root": "/var/www/html/",
              "index": "index.php"
         }
     }
}

// 起動
# service unitd start

// コンフィグの確認
# curl --unix-socket /var/run/control.unit.sock http://localhost/
{
        "listeners": {},
        "applications": {}
}

// コンフィグの変更してみる
# service unitd stop
# mv /etc/unit/config /etc/unit/myconfig.json
# service unitd start

# curl -X PUT -d @/etc/unit/myconfig.json --unix-socket /var/run/control.unit.sock http://localhost/
curl: (52) Empty reply from server

# curl --unix-socket /var/run/control.unit.sock http://localhost/

// レスポンスが返ってこない

// ログ確認
# less /var/log/unitd.log

// ... とくにエラーっぽいものなし。

パッケージのものだとうまく動かない🤔🤔🤔

ということでソースから入れる路線を試す。

// パッケージからのものを消す
# apt-get remove unit

// 準備
# apt-get install git build-essential php php-dev libphp-embed
# cd /tmp
# git clone https://github.com/nginx/unit
# cd unit

// ビルド
# ./configure --prefix=/usr/share/unit/
# ./configure php
# make all

// インストール
# make install
# ln -s /usr/share/unit/sbin/unitd /sbin/unitd

// 起動
# unitd

// 設定してみる
# vim /tmp/unit_config.json

{
     "listeners": {
         "*:8300": {
             "application": "myapp"
         }
     },
     "applications": {
         "myapp": {
              "type": "php",
              "workers": 3,
              "root": "/var/www/html/",
              "index": "index.php"
         }
     }
}


# curl -X PUT -d @/tmp/unit_config.json --unix-socket /usr/share/unit/control.unit.sock http://localhost/
{
        "success": "Reconfiguration done."
}

# curl --unix-socket /usr/share/unit/control.unit.sock http://localhost/
{
        "listeners": {
                "*:8300": {
                        "application": "myapp"
                }
        },

        "applications": {
                "myapp": {
                        "type": "php",
                        "workers": 3,
                        "root": "/var/www/html/",
                        "index": "index.php"
                }
        }
}

// 動作確認
# echo "<?php echo 'hello php';" > /var/www/html/index.php
# curl localhost:8300
hello php

// nginx からプロキシしてみる
# vim /etc/nginx/conf.d/default.conf

upstream unit_backend {
    server 127.0.0.1:8300;
}

server {
    listen       80;
    server_name  localhost;

    location / {
        root   /var/www/html;
        index  index.html index.htm;
    }

    location ~ \.php$ {
        proxy_pass http://unit_backend;
        proxy_set_header Host $host;
    }
}

// 動作確認
# service nginx reload
Reloading nginx: nginx.

# curl localhost/index.php
hello php

出来ているようなので、もう少しちゃんと PHP を動かしてみる。

// phpモジュール追加
# apt-get install php-mbstring php-zip

// composer 導入
# curl https://getcomposer.org/installer > installer
# php installer
# rm installer
# chmod +x composer.phar

// Laravelプロジェクトインストール
# ./composer.phar create-project laravel/laravel app

// Laravel プロジェクトの色々設定
# chmod -R 777 /var/www/html/app/storage/
# php artisan key:generate

// nginx-uniti のルートディレクトリを変更
#  curl -X PUT -d '"/var/www/html/app/public/"' --unix-socket /usr/share/unit/control.unit.sock http://localhost/applications/myapp/root
{
        "success": "Reconfiguration done."
}

// 確認
# curl --unix-socket /usr/share/unit/control.unit.sock http://localhost/
{
        "listeners": {
                "*:8300": {
                        "application": "myapp"
                }
        },

        "applications": {
                "myapp": {
                        "type": "php",
                        "workers": 3,
                        "root": "/var/www/html/app/public/",
                        "index": "index.php"
                }
        }
}


// nginx のルートディレクトリを変更
# vim /etc/nginx/conf.d/defualt.conf

    location ~ / {
        proxy_pass http://unit_backend;
        proxy_set_header Host $host;
    }

# service nginx reload


// 動作確認
# curl localhost

// 何か出ていそうなのでブラウザで開く…!

イエーイ! NGINX Unit で Laravel アプリケーションが動いたぞ~~~空っぽだけど…。

ご覧とおり php-fpm は動いてなくて unit のワーカーが動いてるだけですねー、しゅごい。

# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0  32648  3464 ?        Ss   00:50   0:00 nginx: master process nginx -g daemon off;
root         8  0.0  0.0  18224  2176 ?        Ss+  00:51   0:00 bash
root     26019  0.0  0.0  22196   852 ?        Ss   03:00   0:00 unit: main [unitd]
nobody   26021  0.0  0.0  32440   736 ?        S    03:00   0:00 unit: controller
nobody   26022  0.0  0.0 204620  1440 ?        Sl   03:00   0:00 unit: router
nobody   27293  0.0  0.7 269004 28232 ?        S    03:28   0:00 unit: "myapp" application
nginx    27330  0.0  0.0  33088  2152 ?        S    03:31   0:00 nginx: worker process
root     27331  1.2  0.0  18140  2064 ?        Ss   03:41   0:00 bash
root     27337  0.0  0.0  36572  1588 ?        R+   03:41   0:00 ps aux

現状では Go / PHP / Python に対応しているようで言語環境の準備と configure 時に言語指定すれば使えるようです。

手元にいい感じにお試せるアプリケーションがいないので細かい挙動の様子をみるなど出来ていないのですが、リリースニュース直後からはてぶが盛り上がったり github も盛り上がりを見せている(ように見える)ので、ちょっとしたバグなどなどあってももりもり直されていくんじゃないかなーという予感です。

そのうち Apache + mod_php / nginx + php-fpm / nginx + unit などでパフォーマンスも比べていきたいですねー!

gomiba.co.in を https にした

目次

  • https
  • Let’s Encrypt
  • 導入していく
  • おわり

こんにちは、ごみばこです

実はさらっと、ごみばこいんを https にしてました。
以前にも一度やっていたのですが、何かに詰まり、元に戻していました。またやったら特に問題なく出来てしまったので、何だったんだろう…。。

個人のひっそりページで証明書買うのもなあ、ということで Let's Encrypt でhttps化を行いました。

そのやったことなんかを簡単に説明していきます。

https

http 通信ではなく https 通信にすると、クライアントとサーバ間の通信経路が暗号化されます。
暗号化することによって、なりすまし、改ざん、盗聴といった、第三者による介入を回避することが可能になります。
webを安全に、フリーに扱うことができるようになります。

暗号化は、サーバから配送される証明書(=公開鍵)を用いて、サーバ上の鍵ファイル(=秘密鍵)を使った、公開鍵暗号方式となります。
もっと詳細な https プロトコルについてあまり詳しくはないので、

この証明書は、自分の手でも作ることができますが、信用された機関から発行されたものでないと、クライアントが証明書を信用することができません。
信用された機関も、むやみに証明書を発行することはなく、実在性や正当性を確認したうえで発行します。

具体的にはもっといろいろと計算やサーバ・クライアント間のやりとりがあるのですが、ぼくが https プロトコルに詳しくないので、このあたりで。。汗

こういったwebページが参考になるかもです。
https://www.symantec.com/ja/jp/ssl-certificates/

Let’s Encrypt

https://letsencrypt.org/

Let’s Encrypt は無料で、自動で、オープンな証明機関です。さっきまでの話と異なりますね。

近年のインターネット、webの発達を受けて、もっと安全に利用できるように https を推進している団体(EFF)がいて、ここに web やセキュリティに強い企業が手伝って、いろいろないろいろが出来ているようです。
(詳しく見れていない。。。)

で、今回ごみばこいんは、こちらの Lets’s Encrypt を利用して https にしましたよー、という話です。

導入していく

Let’s Encrypt を利用するには ACME という証明書を発行するプロトコルを使って、証明書を発行する必要があります。
そのプロトコルでやりとりできるツールの一つが certbot です。

ACME プロトコル
https://ietf-wg-acme.github.io/acme/

certbot
https://certbot.eff.org/

ごみばこいんでは、以前 Let’s Encrypt を試そうとしていたところもあったので、一度これを消去します。
※ルートのホームディレクトリに居ただけ

# rm -rf ~/letsencrypt/

certbot を導入します。

# wget https://dl.eff.org/certbot-auto
# chmod a+x certbot-auto

起動確認

# ./certbot-auto 

私の環境では Python 2.6 しかいなかったようなので(!?) Python 2.7 を入れました

# wget https://centos6.iuscommunity.org/ius-release.rpm
# rpm -ivh ius-release.rpm
# yum install python27 python27-devel python27-pip python27-setuptools python27-virtualenv
# rm ius-release.rpm 

再び起動確認

# ./certbot-auto

certbot-auto が使えるようになったことが分かったので、プロパティを設定し、証明書を発行していきます

# ./certbot-auto certonly --webroot -w /var/www/html/ -d gomiba.co.in -m webmaster@gomiba.co.in --agree-tos

ごみばこいんでは nginx を利用しているので、この設定を変更し https を有効にします。

# vi /etc/nginx/conf.d/server.conf 

↓こんな感じのものを書き足しました

server {
    listen 443;

    ssl on;

    # ※certbotを実行したときにパスが出ると思うのでそれを使います!
    ssl_certificate /etc/letsencrypt/live/gomiba.co.in/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/gomiba.co.in/privkey.pem;

    # ※https で使える暗号方式ですが、古い暗号方式は脆弱性があるなどなので無効化するのが吉です
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:!DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!ECDHE-RSA-DES-CBC3-SHA:!ECDHE-ECDSA-DES-CBC3-SHA;


    # 有効なプロトコル
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

    # セッションをキャッシュすることでCPUに余裕を持たせます
    ssl_session_cache shared:SSL:5m;

    # ※ドキュメントルートの設定など
}

※暗号方式のところは、設定後にチェックツールを利用するのがおススメです
https://globalsign.ssllabs.com/

nginx を再起動

# service nginx restart

https で接続ができるか確認し、無事に出来たのでこれにておしまいです。

ちなみに Let’s Encrypt で発行した証明書は90日で期限が切れてしまうので、crontab で自動更新するのが良いです。これは certbot のユーザガイドにも書かれています。

# crontab -e

↓こんな内容を記述

# certbot
0 12 * * * /root/certbot-auto renew -q --no-self-upgrade --post-hook "service nginx reload"

これで Let’s Encrypt がサービス終了にならない限り、ずっと https が利用できます。

おわり

certbot を使うと、簡単に証明書を発行でき https を有効にすることができました。

Let’s Encrypt で発行される証明書を有料の証明書と比べる比べると、企業や団体としての存在証明を行うことはできないので、より信頼性の高める必要のある web サイトで利用することは難しいかもしれませ。しかし、個人で利用する程度のものでは十分だと思います。

安全な web サイトにするためにも、ぜひ使っていきましょう!

ISUCON5 オンライン予選に参加していました

この記事は公開されてから1年以上経過しており、情報が古い可能性があります。

こんにちは。ごみばこです。

以前より気になっていたISUCON、ついに初参加しました。

同じ会社の人もでたいー!と言っていたので、これはいいチャンスだと思っていたのですが、
結果的にみんな予定が…とかでボッチ参戦でした。オコです。とてもかなしい。


ISUCONとは?

「Iikanjini Speed Up Contest」の略で、Webアプリケーションのパフォーマンスをあげようぜ!というものです。
http://isucon.net/


やったこと。

  • 用事のため、12時半ごろからの参加。ぐぬぬ。
  • PHPの実装があやしいということで、再実装する勇気は出ず、Rubyに逃げる
  • 静的ファイルをnginxで返すようにした
      ちょっとだけ上がった。
  • worker_processをあげてみた
      1kくらい上がった
  • relationsをRedisにキャッシュしてみるもうまくできない…
      /initializeで持ってきて、全部そこを使えばいいんじゃね!?!?と思ったけどうまく行かず。
  • footprintのDATE(created_at)をやめる
      ちょっと上がった。
  • / と /login を見直した
      8kくらいまで上がった
  • entriesがアレすぎるのでキャッシュしてみる。
      参照したentriesを全部redisに突っ込む仕様にした。が、スコアが5kまで落ちる。
  • Redisが詰まった…?(????)か、ベンチボタンダブルクリックして2回走ってた…?
      結果よくわからないので戻す。
  • 最後いろいろいじくったら9700くらいになって時間切れ
      インデックス張ったり、ビューの処理をなるたけやめたり。
  • ペプシのストロングゼロめっちゃのんでた。おすすめ
      500mlペットが75円なのめっちゃつよい。

やらなかった、やれなかったこと

  • 過去問で練習
      やろう!やろう!言っててなにもしてない!ひどい!
  • PHPでがんばる
      妥協。PHP7とかHHVMとか試したかったでござる
  • デプロイの仕組みを作る
      1人だし妥協。git pullすらしてない。
  • entriesのカラム調整
      ALTER TABLEに時間がかかりすぎ…。
  • erbをやめる
      erbめっちゃ遅いで。と噂を聞いた程度、実際にloginページはやめた。nginxのプロキシキャッシュも試してみたかった
  • SQLクエリの様子を見る
      スローログの設定がうまくできなかった。アプリ側でログだせばよかったなあ
  • Redisキャッシュ
      やり方がだいぶおかしかったかもしれない。
  • アクセスログの詳細度をあげる
      レスポンスタイムとか見れたはず
  • チームで戦う
      次こそ!
  • erb中のロジック見直し
      終了後によく見たら、もうちょっとだけなんとかできそうな部分あるじゃん…
  • 再起動しての動作確認
      完全に忘れてた。

「1日目、2日目、それぞれで3000点に最も早く到達したチーム (ただし予選終了後の追試の対象には含まれます)」とあったので、ひとまずの目標を3000点にしていました。最終的に1万にとどかないくらいというところで、まあまあ満足する結果になりました。

そんな感じで、1人でも意外といけそうということはわかったのですが、見たいところやいじりたいところが多すぎて、うまく整理できてなかったようです。
もうちょっと、ここがこうでーとか色々メモして、見ていく順番をつけてあげると、自分の動き方がよくなってスコアも伸ばせたかなあ、という印象です

あとは、圧倒的な知識不足を感じました。
以前やっていたとはいえ、Rubyもなんだっけなーくらいだったり、どんなライブラリ使うといいかとかわからないし。
nginxよくわからないし、ミドルウェアもうーん、うーん…、うーーーーーん。

直前で猛練習したり、日頃から触っているような生活じゃないと、いきなりコンテスト!は厳しい感じでした。

あとは1人なのもあって、時間とスコアだけしか見てない動き方だった部分も反省点かなと。

git?いやいや、面倒だから本番いじっちゃおー。_bkとかしときゃいいでしょ。とか。
特定のページだけ静的化とか普通しないけど、スコア伸びたしいいやこれ。とか。
なんでそうなるのかわからないけどこういう設定すりゃいいんでしょwとか。

ということで、次回(もしあれば)は、3人で出る!を目標にがんばります。
本選もいけるなら行きたいけど、楽しいのがいちばんだよね!

最後に、運営のみなさま、楽しいイベントをありがとうございました!