はてなブックマーク

（紹介用にまとめたので最初の3つのディレクトリは本来別のリポジトリで管理すると思います。） 構成図 構成図としてはこのような感じになります。 緑の四角で囲まれたのが一つのdocker-compose、オレンジの四角が一つのコンテナ、黄色の四角はポートバインドです。 これで理解できた人はもう以下を読む必要ありません（笑） 以下各ディレクトリについて説明します。 リバースプロキシ用Nginxです。 これがホストの80番ポートでHTTPアクセスを受け、リクエストされたアドレスに応じてホストのそれぞれのポートにプロキシします。 foo.com.confとbar.com.confはほぼ同じですがupstreamのポートが分かれています。 リバースプロキシのDocker Composeのコツ この構成でNginxは [ホストのIP]:[各サービスのポート] に対してサイトごとリクエストをプロキシしなく

CentOS6系から7系へのアップグレードはアップグレードツールが存在するのですが、このツールは6.7以上で実行すると問題があると書かれているます。 TipsAndTricks/CentOSUpgradeTool – CentOS Wiki 色々ググると6.5からならアップグレードできたという記事が多い反面、6.8からアップグレードしようとしてエラーが出たという記事もありました。 CentOS6.8 から CentOS7 へのアップグレード – demandosigno ↑の記事を読むと、openscapをバージョンダウンさせるといけそうという話があったのでその方法で試してみました。 注意：アップグレード後の起動時にsshdが止まっているのでコンソールアクセスができる状態が必要です。 また一時的にsudoが動かなくなったりする場合があるのでrootのパスワードを忘れないように。 あと他にも

Django 1.6まででは作成後のモデルに変更を加える場合、手動でSQLを発行するかsouthのような外部ツールを使用する必要がありました。 ですがDjango 1.7からMigrationsと呼ばれる新機能でモデルへの変更をDBスキーマに反映できるようになりました。 今までsouthも触ったことが無かったのでこの機会にmigrationsを試してみました。 syncdbからmigrateへ 1.7からはsyncdbコマンドがdeprecatedとなりmigrateコマンドに置き換わります。（1.7リリースノート） なので新しいappを追加した際にもmigrateコマンドで反映できます。 syncdbコマンドも当面は使えるようです。 migrationファイルの作成 モデルに変更を加えた際はまずmakemigrationsコマンドを実行し、migrationファイルを作成します。 pyt

Djangoの1.4以降で追加されたタイムゾーンサポートのことがよくわかってなかったのでドキュメントを読みつつ軽くまとめてみました。 Time zones | Django documentation | Django タイムゾーンサポートの有効化 settings.pyのUSE_TZにTrue/Falseで設定する。 デフォルトでは有効。 概要 タイムゾーンサポートが有効化されていると、日付時刻はデータベースにUTCで保存される。 その際にはDjangoは内部的にtime-zone-awareなdatetimeオブジェクトを使い、テンプレート等で表示するときにユーザーのタイムゾーンに直される。 複数タイムゾーンのユーザーに時刻を表示するときやサマータイム（Daylight Saving Time）対応等で便利。 naiveとaware Pythonのdatetime.datetimeはn