chromeでBasic認証が認証後も出続けてしまう問題
Basic認証をかけているサイトで、一度認証してもページを切り替えるたびにBasic認証が出続ける問題が起きた。
safariで見るとおきないのでどうやらchromeが原因のよう。
調べていくと以下のやりとりを見つけた。
https://serverfault.com/questions/182226/htaccess-requires-password-in-chrome-but-not-other-browsers
要はfaviconなどなにかしらネットワークに401を返すものがあるとBasic認証画で続けてしまう問題があるとのこと。
apacheを使っている場合は、以下のように除外設定を入れてあげるのがよさそう。(例はfaviconをBasic認証から除外している)
<Files "favicon.ico"> AuthType none Satisfy any </Files>
Railsでransackを使った検索を実装した時、検索結果をupdate後も保持するためにしたこと
ransackというgemを利用すると以下のように簡単に検索が実装できる。 こちらの記事がとても参考になった。
Ransackで簡単に検索フォームを作る73のレシピ - 猫Rails
ただindex内でupdateを呼んで更新をかけて、またindexにリダイレクトするような処理をしたかったのだが、 その場合検索結果が保持されないため、以下のように保持されるように処理を作った。
users_controller.rb
def index @search_param = User.ransack(params[:q]) @users = @search_param.result() # 検索パラメータを保持 if params[:q].present? @q = params[:q].permit! end end def update # update処理省略 # 検索パラメーターがなかった場合permit!処理を行うとエラーになるため以下の分岐をさせる redirect_to users_path({q: params[:q].present? ? params[:q].permit! : params[:q] }) end
index.html.erb
<!-- 中略 --> <%= link_to '更新', users_path(user, params: { q: @q}), method: :put %> <!-- 中略 -->
ransackを使って検索を実装すると、params[:q]というパラメーターが入ってくるので、 そのパラメーターを保持してまずviewに渡し、そのパラメーターをupdateまでさらに渡す。
updateで処理終了後indexにredirectさせるときにそのurlパラメーターにparams[:q]をつけてあげれば良い。
bundle install で古いバージョンのgemがmacでインストールできなかった場合の対処方法
自分のrails環境でbundleインストールをした際、
ffiというgemの古いバージョンがインストールできなかったため、以下のように設定ファイルを作成するといいことを教わった。
mkdir .bundle cd .bundle vi config ----- BUNDLE_BUILD__FFI: "--with-cflags='-Wno-error=implicit-function-declaration'" ----- cd .. bundle install
※これはコンパイル時にエラーを発生させないようにしているもので、macのバージョンが上がるとFFIに関してはセキュリティに問題があって古いバージョンを許可していないため起きることがあるらしい。本来は新しいバージョンを使うのがベター。
Kubernetes ingress-nginxで大容量ファイルアップロード等を許可する方法
Kubernetesでアプリケーションを動かしていて、大容量ファイルのアップロードなどを許可する場合、
pod内のnginxやapache、php.iniなどを変更しても、ingress-nginx経由で通信を行っているため、ingress-nginx内の設定を変更する必要がある。
その場合、ConfigMapを設定したのだが、どうもグローバルに設定が反映されない。
kubernetesやingress-nginxのドキュメントをみていくと、Ingressのルールを設定する時のyamlのアノテーションに設定すればいいことがわかった。
以下のように設定した。
apiVersion: extensions/v1beta1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/proxy-body-size: 8m #これを追加 kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/rewrite-target: / name: ingress-nginx-tasien-verify spec: rules: ー中略ー
Flutterのバージョンをダウングレードする
flutterにはダウングレードコマンドがあるが、
自分の環境ではいまいちうまく動かなかったので以下のように実行した。
※flutterをインストールしたフォルダに移動してから実行。
git checkout 1.17.1 flutter doctor flutter --version
「1.17.1」の箇所を任意のバージョンにする。
AWS ECSについて運用、構築、勉強したことまとめ
ECSがぱっと見複雑だったため、構築時に学んだことをメモ。
要素について
クラスター
- コンテナを入れるための塊。EC2とFARGATEが選べる。
タスク定義
- コンテナを起動させる設定。コンテナイメージを指定したり、いくつ起動させるかなどを設定する。
サービス
- クラスターに紐づく。タスクを常駐させるための仕組み。
- webアプリなどのコンテナを起動するタスクをこれに紐づけて常に起動させるようにできる。
- ロードバランサー、ターゲットグループ と紐付けを行うのもここ。
シンプルなウェブアプリ構築の流れ
動くコンテナイメージを作成する
- 試すだけであればdockerhubからnginxの公式dockerimageをもってくるでもOK
ecs-cli コマンドをインストールする
- ecsの操作をコマンドラインで行えるようにする。大体のことはマネジメントコンソールでできるが、ECRにdocker imageをアップロードするときに便利なコマンドがある。
ecs-cli push [ローカルのdockerイメージ名]:[タグ名]
上記コマンドでECRにプッシュできる。
クラスターを作成
- マネジメントコンソールで行う。
- ECSを選択し、クラスターを選択。クラスターの作成メニューを選ぶと、FARGATEか、EC2(Linux)、EC2(Windows)が選べるが、ネットワーク設定のみで簡単なのがFARGATEなのでそれを選択する。
- クラスター名、VPCを作るか、cloudwatchで監視するかくらいの設定で作れる
タスクを作成
- マネジメントコンソールで行う。
- ECSを選択し、タスク定義を選択。新しいタスク定義の作成を選択する。
- FARGATEかEC2を選べと出るので、FARGATEを選択。
- タスク定義名。好きな名前をつける。
- タスクロール(ecsTaskExecutionRoleというのがおそらくあるのでそれを選択)
- タスクメモリ、タスクCPUを規模に合わせて選択。
- コンテナの追加を選択し、コンテナ名欄は、任意の名前。イメージ欄はECRに上げたイメージ、またはdockerhubにあるイメージを選択する。ECRにあげたイメージは、イメージリポジトリのURLが必要だが、dockerhubにある公式なイメージなどは、イメージ名とタグでOK「nginx:latest」みたいに。ポートマッピングは80番等外に向けるために必要なポートを開ける。他は特にいじる必要はないが、ログ出力が必要な場合は、ストレージとログ項目のログ設定の「Autre-configure CloudWatch Logs」にチェックを入れてログ出力をcloudwatchで受け取れるようにする。
- 他沢山の設定項目があるが必須ではないのでとりあえず設定しなくても大丈夫。
- 作成ボタンを押すとタスクができる。
ターゲットグループ を作る
- マネジメントコンソールで行う
- EC2を選択し、ターゲットグループ を選択。
- ターゲットグループ の作成を選択。
- ターゲットグループ 名は任意
- ターゲットの種類はIP
- プロトコルやポートは任意だがHTTPと80が大半のはず。
- VPCはECSのクラスターと同じものを選ぶ。
- 作成ボタンを押す
- 一覧に作成できたターゲットグループ が表示されるので、それをクリック
- 詳細画面にARNがあるのでそれを控えておく。
ロードバランサーを作る
- マネジメントコンソールで行う
- EC2を選択し、ロードバランサーを選択。ロードバランサーの作成を押す。
- Application Load Balancerを選択。
- 名前は任意
- スキームはインターネット向け
- IPアドレスタイプはipv4
- リスナーは80なり443なり任意で選ぶ。
- VPCはECSクラスターと同じもの
- セキュリティーグループを選ぶ時はリスナーと同じポートが空いているものを選ぶ。
- ルーティングの設定でターゲットグループ の選択がでるので、上記で選んだターゲットグループ を選ぶ。
サービス作成
- マネジメントコンソールで行う。
- ECSを選択し、クラスターを選択。作成したクラスターをクリックし、サービスタブを選択。
- 作成ボタンを押す。
- 起動タイプはFARGATE
- タスク定義は先ほど作ったタスクを選択。
- クラスターも同様に作ったものを選択。
- サービス名は任意。
- サービスタイプは任意で良いがREPLICAで問題ない。
- デプロイメント、タスクの配置も任意だがデフォルトで良い。
- 次のステップでネットワーク構成を選ぶので、クラスターVPC、サブネットはロードバランサーと同じものをを選ぶ。セキュリティグループは任意。おそらく80番ポートがあいているものでOK
- パブリックIPの割り当てはENABLED
- ロードバランシング項目では、ALBを選択
- 先ほど作ったロードバランサー、ターゲットグループのARN、コンテナ名などを入力、選択。
- 次のステップでオートスケール設定ができるので、任意で行う。
- 最後に確認して作成。
疏通確認
- ロードバランサーのCNAMEにアクセスしたらコンテナにアクセスできる。(nginxだったらnginxのwelcome画面が出るはず)
その他
タスク(コンテナ)が起動しない
- マネジメントコンソールで、クラスターを選択、タスクタブのStoppedになっているタスクを選択する。
- 詳細が表示されるので、さらにエラーが起きているコンテナを選択し、エラーの詳細を調べる。
※よくあるのがcloudwatchログを作ろうとして権限がないエラーがある。その場合は、作ろうとしているcloudwatchログのグループを事前に作っておくと良い。
ログの確認
- cloudwatchログを設定しておけば、マネジメントコンソールのcloudwatchページで、設定したロググループを選択すればコンテナごとのログが見られる。
- Laravel等webフレームワークなどを利用している場合は、のデフォルトのログ出力設定を標準出力にしておくと良い。
CORSにちゃんと対応しているかチェックするcurlコマンド
CORSに対応したときにちゃんとレスポンスを返せるか以下のコマンドでチェックできる。
この場合、
http://sample.jpは、APIを実行したいURL。
https://your-domain.com/your/apiは、CORS対応をしたAPI等のURL。
curl -X GET -I -H "Origin: http://sample.jp" https://your-domain.com/your/api
大丈夫であれば200が返ってきて、ダメだったら403が返ってくる。