Fusicきばんブログスマートフォン用の表示で見るFusicきばんブログFusic基盤ユニットの非公式技術ブログこの広告は、90日以上更新していないブログに表示しています。Nginxこんにちは桜川です。Docker便利ですね!自分の開発環境はWebサーバーにアクセスするのに、前段にNginxでリーバースプロキシを設置してホスト名を切り替えてアクセスしてます。この方法で基本困ってなかったのですが、地味にめんどくさいのがNginxへのリバースプロキシ設定の追加です。Nginx再起動この設定1分あれば完了する。設定ファイルの管理もめんどくさい。ググってすらなかった。サンプル用にApacheを起動してます。マウントする必要があります。しておいてくださいここまでは簡単でよかった。設置しておく必要があります。なんだけど、開発環境だしホスト名毎にSSL証明書を作るのはちょっと。思ってたらやっぱりありました。使用する証明書を選ぶ機能。設定するとアクセスするときに使用する証明書を選択することが出来ます。default.keyが使用される。default.keyが使用される。リダイレクトされている。デフォルトでは自動でリダイレクトされるみたいです。設定することで自動リダイレクトを無効にできるようです。リダイレクトを無効にするこれで目的を達成!めでたしめでたし。PHP基盤ユニットの貞方(@sadapon2008)です。1.0+CakePHP3+PostgreSQLのテストで嵌った出来事を紹介します。7.0.4が例として書かれています。faultが発生したりします。↓を参考に7.0.x系なら7.0.17を使うのが無難です。デフォルトでxdebugが有効になっているxdebugを有効にしておくとテストの実行時間が長くなってしまいます。必要がなければ、circle.ymlで以下のように無効にしましょう。PostgreSQLのデフォルトの照合順序がen_US.UTF-8になっているこれはPaaS系だとありがちな話ですが、デフォルトの照合順序がen_US.UTF-8と英語になっています。これを解消するには、以下のようにデータベースを作成する際に明示的に指定するのが無難です。'ja_JP.UTF-8';"ただし、日本語のロケールを指定するには自分で追加しないといけないので、circle.ymlで以下のようにしておく必要があります。デフォルトのPostgreSQLのバージョンが変わった場合はパスの変更が必要ですので要注意です。デフォルトのタイムゾーンはUTCJSTに変えたい場合は、circle.ymlで以下のようにします。Linux基盤ユニットの貞方(@sadapon2008)です。Clash脆弱性の対応について調べた情報をまとめておきます。Clashとはセキュリティ企業のQualys社が6月19日に公表した、ローカルからの特権昇格の恐れがある脆弱性です。対象OSはLinux系、BSD系、Solaris系に影響があるとのことです。今のところリモートからの攻撃成功可能性は低いようですが、昔問題になったShellShockのようなものと組み合わさるとまずいです。Qualys社の公表記事はこちらです。根本的にはアプリケーションバイナリの再コンパイルが必要とのことですが、kernelとglibcで影響を軽減するためのアップデートが公開されているようです。kernelとglibcを更新したらシステムを再起動をした方がよさそうです。ここではLinux系のアップデート情報をまとめておきます。Linux(RHEL)RedHat社が特設サイトを開設しています。https://access.redhat.com/security/vulnerabilities/stackguardRHEL5~7のアップデートが公開されています。CentOSCentOS6~7のアップデートが公開されています。UpdateCentOS5はすでに本家のRHEL5が通常サポート終了で延長サポートフェーズになってしまったため、RHEL5のアップデートが一般公開されておらず、CentOS5のアップデートパッケージを作成できない状況のようです。海外フォーラムで見かけたアドバイスとして「有償サポートつきのRHEL5を購入して移行する」というのもありましたがそのあたりはシステム次第でしょう。独自にCentOS5のサポートを提供しているベンダもあるようです。www.miraclelinux.comUbuntu公式の質問フォーラムに情報がまとまっていました。Linuxアップデートが公開されています。ALAS-2017-844ALAS-2017-845AWS全般についてはこちらにまとまっています。PHPカンファレンス福岡2017ですね!弊社Fusicでは前日に会社会議室を開放してクーラーの効いているWiFiスポットを提供しますので、是非ご利用下さい。Fusicは天神にありますしアクセスも良いです。福岡の開発会社をみるいい機会ですよ!fusic.co.jpさらにカンファレンスの次の日は無限ビール(?)を開催します!fusic.doorkeeper.jp楽しみですね!さて、以前ちょっと面倒なDNS設定変更作業がありましたので、その作業手順をメモしておこうと思います。DNS設定変更作業内容1つ1つの作業はただのDNSレコードの設定変更だったのですが、少し面倒で複数のAWSアカウントのRoute53で管理されているHostedZoneHostedZoneも複数HostedZone内の変更対象のDNSレコードも複数それぞれ変更内容が異なるDNSレコードの先にはそれぞれWebサーバが存在。設定変更後も同じWebサーバにリクエストが通る前提というものを、(Webサイトが存在するので)できるだけ短時間に実施する必要がありました。結果として、Codenize.toolsによるコード化ができ、+Rubyスクリプトでの事前のテストで変更内容の確認ができたので心理的ストレスなく当日を迎えられました。Userにつなげました。Roleを作成して連携させています。以下のようになりました。DNSの設定をCodenizeするRoute53の設定は特にコードでの管理がされていませんでしたので、まずはコードで管理できるようにします。Codenize.toolsの1つであるRoadworkerを利用します。RoadworkerはRoute53の設定をコード化して管理運用するツールです。Codenize.toolsの各ツールにはエクスポート機能があるのでいつでもコード化できます。以下のようにRoute53の設定をRoadworkerのexport機能でエクスポートしました。CodenizeしたDNS設定を使って、別のAWSアカウントでテスト環境を構築するエクスポートしたRoutefileを使って別のAWSアカウントでRoute53のテスト環境を構築します。Routefile.cこれで本番環境のDNS環境(本番DNS)とテスト用のDNS環境(テストDNS)ができました。HTTPリクエストのテストを作成する本番環境NS、テスト環境NS、そして(念の為)GoogleのNSを使ったHTTPリクエストのテストを作成します。HTTPリクエストのテストは取得したHTMLに期待する文字列が含まれているかどうかの簡単なテストです。以下のような感じで構築しました。endendこれで、本番環境NS、テスト環境NS、GoogleのNSの3つにおいて正常にHTTPリクエストが通るかどうかのテストができました。今回はテストDNSというものがあったので利用していません。テストDNSのDNSレコードの設定を変更するテストDNSを今回の変更内容に合わせて変更します。オプションで一気に適用できるから便利ですね。Routefile.c先ほど4で作成したHTTPリクエストテストを実行して、DNSレコード設定変更後も正常にHTTPリクエストが通ることを確認します。Routefile.c再度、先ほど4で作成したHTTPリクエストテストを実行して、DNSレコード設定変更後も正常にHTTPリクエストが通ることを確認します。まとめインフラの設定をコード化(Codenize)することによってその後の作業を効率化、さらに作業漏れの軽減ができました。Rubyで「リゾルバを変更する」という処理を書けることで、事前のテスト検証も実施できました。今回のDNSがAPIで設定変更可能なRoute53でなかったと思うとちょっとツラいですね。同じようなDNS設定変更があった場合の、何かの参考になれば幸いです。Slack)こんにちは。基盤ユニットの濱野です。使ってみた話を書いてみようと思います。mockmockはIoTの開発支援サービス。クラウド上に仮想デバイスを作成し、開発中のサーバーに疑似データを送ってくれる。デバイスの制約を受けずにIoTのサーバーアプリの開発が進められるので、とっても楽。