2017-12-22

MackerelとUptimeRobotでサークルのサーバを監視している話

サーバ

どうも千葉大電子計算機研究会(以下CCS)、老害㌠いかろちゃんです． CCS Advent Calendar 2017 の22日目の記事として MackerelとUptimeRobotでサークルのサーバを監視はじめた話を書こうと思います．サーバ構築の話についてはこちらの記事Ansible+Dockerでシンプルにサークルのサーバを管理しはじめた話 - まどろみの思考空間で書いています．

前日のアドベントカレンダーの記事はこちら↓ nirup.hatenablog.com

はじめに

サーバは構築して終わりではなく，むしろその後，継続してサービス(たとえば，サイトなら表示できるとか)を提供することが重要です．継続してサービスを提供するには，サービス提供できていない状況(=異常)を検知する必要があります．そのため，監視をする必要があります．

しかし監視をすることには色々な点でコストがかかります．まず，監視対象とは別の監視拠点を用意しなくてはなりません．これは監視対象と監視拠点を一つにした場合，障害の内容によっては検知できないことがあるためです．また，監視拠点が落ちてしまっても監視を継続できません．そのため，通常は複数拠点による監視が必要です．また，それらの監視拠点を自前で保つ場合は監視拠点のメンテナンスコストもかかります．

そしてサークルでは(サークルでなくてもですが)予算は限られています．また，潤沢にサーバ管理に投入できる人的リソースがあるわけでもありません．また，代替りが頻繁に行われるため，あまり複雑なことをしてよくわからないけどうごいているものをふやすことも得策でもありません．そこでいかにこれらのコストを下げるかということが重要になってきます．

　監視の構成

サークルのwebサイトは商用サイトと比べクリティカルな案件ではありません．したがって，サービスのダウン検知だけを行えれば良いというのが最低条件です．また，即座にログインできるとはかぎりませんのでできるかぎりメトリクスはとっておきたいです．そこでサイト表示不可，ユーザから見て正常に動作していない状況ではアラートを出す，それ以外はメトリクスをとるのみという方針にすることにしました．

メトリクス収集にはMackerelを利用しています．これは下記の理由によるものです．弊サークルではIDCFクラウドを利用しています．そのため，MackerelのIDCFプランが無料で利用できます．通常のFreeプランとの違いはホスト数が無制限であること，グラフ表示期間が1週間であることです． Mackerelでは基本的にメトリクスのみを取るようにしています．とっているメトリクスは下記となります．また，wikiと階委員専用ページはdockerで動いています．そのため，dockerのメトリクスを取るようにしています．例外的に「ログ監視」と「ディスク残量」の監視は行っています．

外形監視にはUptimeRobotを利用しています．これはMackerelでは外形監視を無料枠ではできないためです．弊サークルのサイトは「トップページ」，「Wiki」，「会員専用ページ」の1つの静的ページおよび，2つのWebアプリケーションで構成されています． UptimeRobotではこの3つのそれぞれのトップページを文字列検知で監視しています．

議論

UptimeRobotでの外形監視は正常にサービスを提供できているかの基準で監視を行っています．そのために，特定Webアプリケーションがみれないということを防ぐため，アプリケーション単位で外形監視を作っています．単に疎通ではなく，監視文字列検知にしている理由は以下のとおりです．ひとつめはアプリケーション側の何らかの不具合により200(正常ステータス)を返しているものの必要な情報を提供できていないことを防ぐためです．アプリケーション側の不具合により，空白ページが発生してしまっても疎通確認ではこれを検知することはできません．二つ目の理由は改ざん防止です．悪意がある変更がhtmlに加えられた場合でも監視文字列未検知で検知できる可能性があります．もちろん，html全体の変化を追跡しているわけではないので，微妙な変化には耐えられませんが，通常の運用では監視文字列検知でよいと考えています．

mackerelでの監視は外形監視では検知できないがサービス影響が出る可能性があるもの，サービス影響はないものの，対応に時間が掛かる可能性があるものを監視する方針としてします．サークルのサーバではありませんが，運用している別サービスではログ監視を複数いれています．これはエラーログにエラーがでていて使えない機能がでていたものの，外形監視で検知できていなかったためです．ディスク残量はファイル削除で対応できる場合は問題がありません．しかし，ディスク増設が必要な場合は金銭的問題もありサークルでの承認を得る必要があり対応に時間がかかるため監視をしています．

サークルのサーバではあまり障害が起きていないので，同様にUptimeRobotとMackerelで監視している別サービス(shimaidon.net)でのアラートと状況について書きます．理想は障害発生時に即座にログインで対応することです．現実には仕事でしているわけではないためつねに見張ってるわけにはいきません．したがって障害時のリソースをサーバにログインしてとることができないことがあります．しかし，メトリクスをMackerelでとっているため，あとからでも当時のリソースをある程度は復元できます． 1週間分のデータでも周期的な変動でまた起きる可能性があることかどうかが推測できます．これは再発防止策を考える必要があるかの判断基準として助かっています．また，検知できなかった障害については監視項目追加，対応が不要だった項目については抑制という方針をとっています．

まとめ

UptimeRobotで外形監視を，Mackerelでメトリクスをとることで低コストで監視が行えるよという話でした．

明日は@here_1115氏です！

2017-10-24

MacでX11 Forwardingで接続が切れる問題をどうにかした

わたしの研究室では手元のクライアントから計算機(Linuxマシン)にsshで繋いで作業をすることが多い．作図なんかも多くの場合繋いだ先の計算機で行う．その際に作図した図の確認をするためにGUIが必要である．手元にもってきてもいいがsshでつないでGUIを使う方法としてX11 Forwardingがある．

困ったことになぜかMacからつなぐとX11 Fowardingがなぜか途中で切れる．この現象がなかなか解決せずここ数年放置してたものの，いちいちつなぎ直すのも面倒なのでついに調べてみた．結論から言うと手元のsshの設定で「X11 Fowarding」を設定すればよかった．

今まではTCPKeepAliveしても改善しないなぁと思っていた．なにか他に設定できるところはないかssh_configのmanをよく読むと下記があった．

     ForwardX11Timeout
             Specify a timeout for untrusted X11 forwarding using the format described in the TIME FORMATS section of sshd_config(5).  X11 connections received by ssh(1) after this time will be refused.  The
             default is to disable untrusted X11 forwarding after twenty minutes has elapsed.

つまり，sshのコネクションだけではなくX11のタイムアウトもありそれがデフォルトだと20分で切れるということらしい．そこでこのForwardX11Timeoutの値を24hに設定してあげた．結果，今のところ切れずに使えている．

結論．manをちゃんとよんで設定しましょう．

2017-05-07

MastodonでIDCFクラウドのオブジェクトストレージを利用する

Linux サーバ Mastodon

はじめに

最近Mastodonが流行っていますね。そこで@reki_frequent 氏と一緒にshimaidon.netというインスタンスをたちあげました。

AWSを使う手もありましたが料金の魅力からIDCFクラウドを選択しました。 IDCFクラウドでとりあえずたててみたという記事は他にも多数ありますので、建て方については他の記事に譲るとして本記事ではオブジェクトストレージを使用して料金を節約する方法を紹介します。

Mastodonとは

Mastodonとは分散型ミニブログの規格であるOStatusのOSS実装の一つです。そのため誰でもインスタンスをたてることが可能です。またインスタンス間の協調も定義されています。したがって特定の組織に依存しないSNSのネットワークを構成することが可能です。

Mastodonを個人で運営していく上での問題点

Mastodonを運営していく上での問題の一つに画像等で大量のディスク容量が必要とされることが挙げられます。他のサーバリソースは登録者の制限等で一定水準に保つことが可能ですがディスク使用量は少人数しかいないインスタンスでもどんどん消費されていきます。そのため安価にディスク容量を確保することは個人でMastodonを運営していく上で重要となります。 IDCFクラウドは通常のストレージよりオブジェクトストレージを使用したほうが安価(しかも50GBまで無料で使える)です。 IDCFクラウドのオブジェクトストレージはAWSのS3との高い互換性を謳っています。また、MastodonではS3をストレージとして利用することが可能です。したがって、IDCFクラウドのオブジェクトストレージをストレージとして利用することが可能です。

実装

本例の環境はCentOS7.3.1611でmastodonのバージョンは1.3.2を利用しています。

実装方針としては.env.productionに設定を追加することでMastodon側でオブジェクトストレージを利用する設定にします。 IDCFクラウドのオブジェクトストレージの課金の特徴としてIDCFクラウド内の通信は無料です。そこでVMのnginxを必ず経由させるようにしてさらに利用料を抑えます。

shimaidonの場合.env.productionに追加した設定は下記です。

S3_ENABLED=true
S3_BUCKET=shimaidon
AWS_ACCESS_KEY_ID=<API Key>
AWS_SECRET_ACCESS_KEY=<Scret Key>
S3_REGION=ds.jp-east
S3_ENDPOINT=https://ds.jp-east.idcfcloud.com
S3_PROTOCOL=https
S3_SIGNATURE_VERSION=s3
S3_HOSTNAME=shimaidon.net/s3_contents

S3_ENABLEDでS3を有効にするかどうかの設定をします。 S3_BUCKETは使用するバケットを指定します。このバケットは予め作成しておきます。例ではshimaidonというバケットにしました。「AWS_ACCESS_KEY_ID」、「AWS_SECRET_ACCESS_KEY」はそれぞれ適切に設定してください。 S3_ENDPOINTはエンドポイント、S3_REGIONはエンドポイントから「idcfcloud.com」を取り除いたものとなります。 S3_PROTOCOLはhttpsです。 S3_SIGNATURE_VERSIONはIDCFクラウドはv4に対応していないのでs3としてください。 S3_HOSTNAMEですがnginxでオブジェクトストレージにproxyさせるため「<自ドメイン>/<サブディレクトリ>」としてください。今回の例ではshimaidon.net/s3_contentsとしてあります。サブディレクトリ名は当然ですがmastodonのものと被らないように気をつけてください。

次にnginxの設定です。雑に下記のようにしてあります。

        location /s3_contents/ {
            proxy_set_header host $host;
            proxy_pass https://ds.jp-east.idcfcloud.com/;
        }

/s3_contents/に来たアクセスをs3_contentsを取り除いたファイル名をhttps://ds.jp-east.idcfcloud.com/ に転送しています。

今回は料金を下げるという点に注目しました。最後のnginxでリバースプロキシさせるというのは料金とトラフィックやサーバの負荷のトレードオフとなっています。お金にものを言わせて大規模インスタンスを運営する際はnginxを経由させないようにS3_HOSTNAMEをds.jp-east.idcfcloud.comにするほうがよいです。お金があるならAWSでPaaSを駆使したほうがよさげではありますが。

まとめ

本記事では各種クラウドの中でも比較的安価なIDCFクラウドを用いてさらにそのオブジェクトストレージを用いることで料金を下げる方法を紹介しました。具体的にはS3とIDCFのオブジェクトストレージが互換性があること、IDCFクラウド内での通信は無料であるという特性を利用しました。このような形態の運用はお金のない個人インスタンスを運営する上で有用です。

2017-01-04

2016年サークルのサーバの障害まとめ

サーバ Linux

新年あけましておめでとうございます．新年早々，障害の記事なんてって感じですが年越し前に書くつもりがこんな時期になっていました… 障害があったことは年超えても忘れずに今後にいかしていきましょうということで…

さて，本日の話題は去年にサークルで発生した大きめの障害(単純な再起動等では復旧しなかったもの)のまとめです． 2つとも人為障害でした…

事例1:パーミッションの設定忘れによる一部ファイル閲覧不可

下記が対応ログより抜粋

　　　nginxログ確認
　　　　→下記出力を確認
> 2016/10/20 21:48:08 [crit] 35340#0: *6 open() "/var/lib/nginx/tmp/proxy/2/00/0000000002" failed (13: Permission denied) while reading upstream, client: 133.82.251.196, server: _, request: "GET /only/static/file_management_rule.pdf HTTP/1.1", upstream: "http://127.0.0.1:8082/only/static/file_management_rule.pdf", host: "densanken.com", referrer: "http://densanken.com/only/"
    
　　　/var/lib/nginx/配下の権限確認
　　　　→nginxユーザが所有者であることを確認
> [root@main01 /]# ll /var/lib/nginx/
> 合計 0
> drwx------ 7 nginx nginx 73 10月 16 19:37 tmp

　　　/var/lib/nginx配下の所有者変更実施
　　　　→正常に変更できたことを確認

nginxの実行ユーザをwebadminにしたのですが，"/var/lib/nginx/“の権限を変え忘れて死んでたという感じです．対応ログではさくっとnginxのエラーログ見て対応してみたいに書いていますが，最初はアプリケーション側の障害を疑ってました．「推測するな．計測せよ．」，通信経路順におっていけっていう教訓です．

事例2: SSL化にともなってhttpとURLが記載されていた場所が死ぬ．

Webアプリケーションにhttpと書かれていた部分によって引き起こされました．下手にhttp→httpsにリダイレクトしていたため，なぜか更新ができないという一見，SSL証明書と関係ないバグのような感じで手間取りました．

最終更新日を確認するとSSL化した日付以降更新がないのでもしやと思ったらビンゴでした．

まとめ

今回の障害はサーバの設定を行う時に確認すべき項目が整備されてなかったことによるものでした．面倒ですが，

設定変更したときに意図しない動作をするようにしていないか確認手順を設ける
機械的にテストできるものはテストする

ようにしましょう(といいつつしてないので今度メインで管理している後輩たちに投げたい)

2016-12-06

Ansible+Dockerでシンプルにサークルのサーバを管理しはじめた話

サーバ Linux Docker Ansible

どうも千葉大電子計算機研究会(以下CCS)、老害㌠いかろちゃんです。 CCS Advent Calendar 2016 の6日目の記事として老害なので現役生を差し置いてサーバ管理をしちゃってる話を今日は書こうと思います。

サークルでサーバ管理をする上での問題点

大学サークルの特徴(少なくともCCSは)として下記があります。

人間の流動が激しい(役職は一年交代)
様々なWebアプリケーションがデプロイされる可能性がある
予算がその年のサークルの人数によって決まる
仕事でしているわけではないのでかけられる時間が限られる

したがって

サーバを構築した人が連絡がつかず誰も構成を把握・対応できなくなる
環境がコンフリクトしてしまい最悪各種サービスが提供できなくなる
いつIDCの変更を余儀なくされるかわからない
時間的制約で後回しにされがち

といった問題があります。

これらの問題を解決するために構成をシンプルにしてAnsible+Dockerでコード化をすすめてみたよというのが今日のお話。今後CCSのWeb管になる人、他のサークル等で同様の悩みを抱えている人の参考になれば幸いです。

技術選択

クラウド

会室にサーバ機を置くのはネット回線を引く手間、盗難・火事等が怖いのでまず最初に却下としました。クラウドとかVPSの候補としてはAWS、GCP,IDCFクラウド、さくらVPS、ServersMan@VPSが候補に。料金・拡張性を考えてIDCFクラウドとしました。 IDCFクラウドなら最低ワンコイン(オブジェクトストレージつかうともっとさげられますが...)からはじめられます。 (ServersMan@VPSは安いけど前使った感じあんまり印象が良くなくてお遊び以上には使えないなーっていう感じがあったので却下)

お金があるんだったらAWSとかGCPのPaaSをがんがんつかっていくというのがよい選択な気がします。

OS

現在はCentOS7を使っています。これは最近のものがまぁまぁ動いてかつ枯れていて、サポート期間も長いため選択しました。過去にCoreOSやFeodraつかってみましたが、CoreOSは小規模環境ではただただつらい、 Fedoraはサーバ機でする選択ではなかったですね...

構成管理

構成管理ツールのひとつであるAnsibleで構成管理を行っています。 Ansibleを使い構成をコード化することで(Ansibleがわかる人なら)誰でもサーバの構成を把握しやすくなりました。また、将来のクラウド移転を行うことになった際もだいぶ楽なはずです。

Ansible特徴としてはエージェントレスであることYAMLで記述するため比較的設定がシンプルであることが挙げられます。 Chef-soloなんかでもいい気も一瞬しましたが、シンプルにできることはシンプルに済ませるというのが引き継ぎや作業のコスパを考えるといい気がしたのでAnsibleを選択しました。

Webアプリケーション

ここでコンテナ型仮想化技術のDockerです。これでAnsibleを導入したのと同様の環境のコード化を手に入れ、また環境がホスト・他のDockerコンテナと分離されるのでコンフリクトを気にする必要がなくなります。

Webサーバ

軽量・高速なWebサーバであるNginxを採用しました。 Nginxで静的サイトの配信及びWebアプリケーションへの振り分けを行っています。各種環境に依存するサービス、特にWebアプリケーション(というか今はWebアプリケーションしかコンテナ化してない...)をコンテナ化しました。

監視

外形監視にはUptimeRobotを利用しています。 ~~また，内部のリソース管理にはNagiosを利用しています。~~ Mackerelを使い始めました(詳細はこちらMackerelとUptimeRobotでサークルのサーバを監視している話 - まどろみの思考空間)

Nagiosを利用しているのはわたしが慣れているからという理由だけなのでZabbixでもMackerelでもなんでもいいと思います。

コードの管理

Ansibleのplaybook, DockerのDockerfile, そしてコンテンツ系のソースコードの管理はGitHubで行っています。 gitによるバージョン管理を行うことで構築でミスって障害を引き起こしても最悪直前の状態までもどせるという安心をえることができます。学生ならアカデミックライセンスがつかえますのでプライベートリポジトリもつかえていい感じです。

実装

仮想マシンの立ち上げ・基本設定

IDCFはCloudStack APIに対応していますのでAnsibleのCloudStackモジュールを利用することで上位のファイアウォールの設定はもちろん、VM インスタンスを自動的にたてて基本的な設定をするといったことまで可能です。これは下記を参考に実装しました。

AnsibleでCloudStackを操作する（基礎編：仮想マシン作成とプロビジョニング） - Qiita

ユーザはセオリー通りsudo権限を持つ管理者ユーザ、webコンテンツの管理者ユーザ(sudoは不可)を用意しました。 webコンテンツの管理者ユーザはDockerの各種コマンドが実行できるようにdockerグループに入れてあります。

SSL証明書の取得

世の中の常時SSL化の流れにしたがってCCSでもすべてのページを原則https化しています。

SSL証明書の取得にはLet's Encryptを利用しました。 Let's Encryptを使うと無料でSSL証明書を取得できます。また，コマンドラインで取得，更新が可能ですので非常に自動化向きです。 certbotをyumでいれて定期的に更新するようなcronを仕込めば完了です。 Ansible化するための注意点としてSSL証明書の取得のコマンドをそのまま叩いてしまうと冪等性が保証されないので --keep-until-expiringオプションを付ける必要がありました。

Nginx

これもAnsibleで管理です。特に細かいチューニング等はしていません。また，一時期動的にdockerコンテナにproxyする実装にしようかと思いましたが，実装コストを考えて手動で設定ファイルを書き換えて各種コンテナにproxyさせるようにしています。必要になったら実装すればよいでしょう。

監視

例のごとく監視設定，監視エージェント(NRPE)もAnsibleで管理しています。監視項目で特にかわっている点としてはサーバにSWAPがないのでメモリ使用量監視にしているということでしょうか。これには下記のプラグインを利用しています。

GitHub - koemu/nagios_plugin_check_memfreetotal: Checking overall memory free space (RAM + Swap) plugin for Nagios.

また，コンテナの起動監視もしたいと思っていて，現在こちらのプラグインを作成中です。

監視サーバは暫定的にわたしの個人契約しているのを利用しているのでそのうち移行~~したいと考えています。~~しました。 Mackerelに移行した記事はこちら(詳細はこちらMackerelとUptimeRobotでサークルのサーバを監視している話 - まどろみの思考空間)

コンテンツ系

先程説明したとおり，WebアプリケーションはDockerで管理しています。基本的に揮発しても良いものはDockerfileにかいて、データはVolumeでマウントするようにしています。 gitで管理はしているものの，基本的に手動でデプロイです。ポート番号とかも手動管理... これはいけてないのでそのうち直したい...

実際に運用してみて

メリットとしては作った本人も構築当時の設定等をわすれてしまうもので，何かあったときとりあえずGitHubをみて設定を確認できるってのは便利だなって思ってます。今までは構築担当者が死んだらサーバの構成は闇の中でしたがそういったこともなくなりました。また，教える時に余計コストが増えるかと思いきやAnsibleやDockerの概念さえ教えてしまえば、細かいところに気をとられることなくざっくりと教えられる、ダブルチェックの手間が減る等で時間的コストを大幅に減らすことに成功しました。具体的には昔は構築は教えながらだと2,3日fullでしても終わらないとかでしたが今は最短数秒，教えながらしても合計12時間程度の時間になりました。

今回サーバ構成で意識したこととしては、要求を満たしかつ凝りすぎないということです。再利用性や柔軟性をかんがえたり、もっとストイックに全部Dockerで管理したり... ともっとやろうと思えば色々できたと思います。ただそういうことをしてしまうとメリットをデメリットが上回ってしまいます。また、シンプルなシステムのほうが壊れにくいし何かあっても対処しやすい。そういったことを考えて妥協点を探るというのが特にサークルのサーバような必要経費ではあるものの全力でそれに時間をかけているものではないといった場合に必要なのではないかと思います(もちろんお金があるんだったら専門の会社とかにアウトソーシングとかもありなんでしょうけど...) 実は明らかな技術的負債も作り込んでしまっていますが、これはきっと後輩たちが解決してくれるでしょう(他人任せ

ただ，緊急で対応したいとかテストしたいとかのときになかなか面倒だなーっていうところはあるのでそういったのに対応しやすいPlaybookとかかきたい(テスト環境をいい感じに整備することもふくめ)なあといった感じです。

まとめ

サークルのような低予算かつ人の流動が激しい環境ではAnsible+Docker等で出来る限り環境のコード化する，構成をシンプルに保つことで幸せになれるかもというお話でした。

次は @littlebird514 君の予定です。よろしくおねがいいたします

2015-11-30

Fedora22で突然dnfが使えなくなって解決した話

dnf updateするかーとおもっていつものように

sudo dnf update

とすると

Traceback (most recent call last):
  File "/bin/dnf", line 36, in <module>
    main.user_main(sys.argv[1:], exit_code=True)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 198, in user_main
    errcode = main(args)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 84, in main
    return _main(base, args)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 117, in _main
    cli.configure(map(ucd, args))
  File "/usr/lib/python2.7/site-packages/dnf/cli/cli.py", line 1006, in configure
    self.base.plugins.run_init(self.base, self)
  File "/usr/lib/python2.7/site-packages/dnf/plugin.py", line 104, in run_init
    plugin = p_cls(base, cli)
  File "/usr/lib/python2.7/site-packages/dnf-plugins/system_upgrade.py", line 359, in __init__
    super(SystemUpgradePlugin, self).__init__(base, cli)
TypeError: must be type, not None

とエラー。

調べてみると https://github.com/rpm-software-management/dnf-plugin-system-upgrade/commit/4bbbf1ec0c3f387249d30dd103ff4d002c17f574 に行き着いた。 Python2のユニコード周りのバグらしい...

Unfortunately, Fedora 21 and Fedora 22 don't have that

ほんとに不運だ...

ちゃんと修正されたソースコードはあるのでそれをDLして現状のものを置き換える(念の為バックアップもとっておく)

# cd /usr/lib/python2.7/site-packages/dnf-plugins/
# cp system_upgrade.py{,.bak}
# wget https://raw.githubusercontent.com/rpm-software-management/dnf-plugin-system-upgrade/4bbbf1ec0c3f387249d30dd103ff4d002c17f574/system_upgrade.py

これで解決した。

2015-10-15

PyCon2015に参加してきました #PyConJP

1日目

Pragmatic Logging and Metrics

Pythonっぽい話かなと思ったら、わりとインフラよりのお話。「fast/once/context」を実現するためにどうするか? まずはSentryの紹介。アプリケーションの例外をSentryに送って、そこからSlack等へ配布。 fluentdに近いイメージ?

次にGrafanaとかいろいろ。メトリクスを収集して表示的な感じ(いろいろあって把握しきれてなかった...)

そして、各種のログ出力をいい感じに整形して渡してくれるstructlogというのを書いたよという話。

Python と型ヒント (Type Hints)

Python3.5で導入された型ヒントについて。大雑把にいうとイケメンではあるけれども、それと同時に弊害・理想と現実という問題もあるというのも現実というような感じの内容。

プログラム全体が対応していないとあんまり意味がないっていうのはC++のconstみたいな感じだなって思った。

今後漸次的型付け(Gradual Typing)ってのは色々なところでいわれはじめそうな気がするので、はやめに把握しておきたい。

組合せ最適化を体系的に知ってPythonで実行してみよう

タイトル通り。組み合わせ最適化の紹介と実用例。基本的にには解きたい問題をパターンに落とし込んでソルバに入れてあげれば答え出るねという感じ。

組み合わせ最適化問題は標準問題と数理問題という二面から捉えることができる。一般的に標準問題のほうが、早くとけることが多い。

わりと数学的なようで実用面結構ありそうだなという感触だった。解くということに関しては、もうライブラリが充実しているので各アルゴリズムの特性とかを理解するのが良いのかなという感触。

なぜWeb画面自動テストはうまく行かないのか

Seleniumでいけそうだけど、現実問題(マルチブラウザ、パラメータ変更コスト、環境容易コスト)からうまくいかないのでラッパー作りましたという話。

環境に依存しないCoreと、あって状態(パラメータ)を記述するファイルというのはServerspecとかもそういうような感じになっていてWeb画面自動テストに限らずテストのフレームワーク作る際の定石なのかなという印象。

MinecraftをPythonで遊ぶ

登壇者が若くて驚いた。 mcpiをつかってPythonからMinecraftをいじると楽しいよという話。

Minecraftで遊んだことないけど、こういう遊び方もあるのかと3000円払いたくなってきた。発表の中でいわていた学習というコンテキストで語られる機会の多いmcpiだけど、そうじゃなくて楽しいからやってみるっていうのとても大事だなって思う。

いま求められるコミュニティの多様性と未来

コミュニティについてのパネルディスカッション。色々と考えさせられた。

この中で入りやすいコミュニティ大事という話があったけど、 C++のコミュニティとかここらへん真逆なあれだよなっていう感じがした。

懇親会

ビールばっかり飲んでたｗ前から会いたいなーっておもってたこくたんと話せてよかった。 Twitterと同じように面白い人だった。

2日目

PythonとPyCoRAMでお手軽にFPGAシステムを開発してみよう

物理デバイスをつくるプログラムが書くの大変なので、 Pythonラッパーを作ってみましたというお話。

FPGAはあまり興味わかなかったけど、 Pythonの構文木をいじれるってのは面白いなって思った。

uWSGI/Dockerを利用したWebサービス運用事例

わたしはgunironユーザだったけど、パフォーマンスも良さそうだし、機能豊富だしuWSGI使ってみようと思った。 uWSGIのReuse-Portがダウンタイムを最小にしていい感じにできるらしい。

Dockerはよく言われる壊れることを前提にする的な話だった。

セカイノカオ by チーム・カオ

発想がぶっ飛んでた。こういうアートとITの融合みたいなのおもしろいなーって思う。

Rise of the Static Site Generator

WordPressみたいなCMSな動的サイトは確かに便利なんだけど、重かったり、攻撃の対象になったりとか色々と問題が多い。そこでStatic Site Generator(有名ドコロだとMT?)で解決しましょうという話。 Python製のPelicanが紹介されていた。

唯一聞き取れた英語セッションだったのでうれしかった。(もっと英語力高めたい....)

※あとでまた追記するかも

はじめに

監視の構成

議論

まとめ

はじめに

Mastodonとは

Mastodonを個人で運営していく上での問題点

実装

コメント

まとめ

事例1:パーミッションの設定忘れによる一部ファイル閲覧不可

事例2: SSL化にともなってhttpとURLが記載されていた場所が死ぬ．

まとめ

サークルでサーバ管理をする上での問題点

技術選択

OS

構成管理

Webアプリケーション

Webサーバ

監視

コードの管理

実装

仮想マシンの立ち上げ・基本設定

SSL証明書の取得

Nginx

監視

実際に運用してみて

まとめ

1日目

Pragmatic Logging and Metrics

Python と型ヒント (Type Hints)

組合せ最適化を体系的に知ってPythonで実行してみよう

なぜWeb画面自動テストはうまく行かないのか

MinecraftをPythonで遊ぶ

いま求められるコミュニティの多様性と未来

懇親会

2日目

PythonとPyCoRAMでお手軽にFPGAシステムを開発してみよう

uWSGI/Dockerを利用したWebサービス運用事例

セカイノカオ by チーム・カオ

Rise of the Static Site Generator

　監視の構成