はじめに
当社ではBIツールとしてredashを利用しており、つい先日v10へのアップデートを行いました。その際の記事はこちら。
今回はそんなアップデートにてECSタスク定義を変更した際、定義内に\tが紛れ込んだことでredashが不具合を起こした話をまとめます。
0. 事の起こり
アップデートの喜びも束の間、Pythonが利用できないといった報告が入り、その解決に奔走することとなりました。確認の為にデータソースpythonにてTest Connectionを発行するもNoneType object has no attribute test_connectionと弾かれてしまいました。
当社ではv8以前の頃からredashにてPythonを利用しております。その為アップデートに際しても、検証環境にてPythonが利用できることを確認した上で同様の設定を本番環境に施しており、これは不可解な症状でした。
1. 結論
タイトルに記載の通りタスク定義の環境変数欄に\tが混入しており、環境変数として機能していなかったのが原因でした。当該タスク定義のJSONが以下の部分ですが、環境変数REDASH_ADDITIONAL_QUERY_RUNNERSの末尾に\tが入っています。
厄介なことにこれは見かけ上は判別が困難でした。
以下はクラスターのタスク画面とリビジョン作成画面のスクリーンショットですが、それぞれ\tが混入していた際のものです。
細かい定義の見直しを行うべくJSONによる設定画面を開いたことで発覚しました。
REDASH_ADDITIONAL_QUERY_RUNNERSが認識されず、冒頭のエラーになっていたようです。
また、別のコンテナではcould not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?といったエラーログを吐いていたのですが、これも同様にREDASH_DATABASE_URLの値の方の末尾に\tが混入していた為にPostgreSQLに接続できなかったようです。
まとめ
実の所、どのタイミングで\tが紛れ込んだのかは分かっていません。検証環境のJSONを移し替えるためにコピペ行った際にでも紛れ込んだのか・・・？といった具合です。手作業での設定の悪い側面が出てしまったかなという印象ですね。こうした人為的ミス、及び修正にかかる工数を考えれば、Infrastructure as Codeで自動化することを本格的に考えねばならないなと思いました。