お一人様のMastodon - Qiita
Mastodonを見ていたら、SINGLE_USER_MODEという設定項目があった。 トップページはアカウントID=1のストリームに固定(リダイレクト)される /aboutからサインアップできない。(入力はできるけど、トップに戻り何も起きない) Adminの管理はできる 公開インスタンスリストにも3つばかりSingleな奴がいますし、作ってもいいんじゃないかと。 List-of-Mastodon-instances SINGLE_USER_MODEをセットアップする まずは普通に立ち上げよう。準備。 cp .env.production.sample .env.production vim .env.production rake secretを埋めたり。 手元でやってみる場合、LOCAL_DOMAINはとりあえずlocalhost:3000を入れとくとよいです。 Rails的な色々をし
STNSのバックエンドをつくろう - Qiita
この夏、あるシステムでSTNSを使えそうな気がしました。 STNSとは何か、ですって？ なら落ち着いて、時代が求めたSTNSと僕 // Speaker Deck を読みましょう。 OK、読みましたかね。 で、ユーザのDBにSaaSの何かを使えればいいなとおもってバックエンドを書けるかなという試み。時代とはつまり私だった。 この記事で出てくるコードを置きました。 https://github.com/sawanoboly/stns_backend-sinatra-example STNSのバックエンド仕様を調べました 注: こちら、記事作成時点のSTNS APIバージョン1.0の仕様についての調査です。※バックエンドの指定にv2をつけなければそのまま使えます。 API v2.1(またはそれ以降)については http://stns.jp/en/interface STNS製作者のP山さん曰く、
Amazon ECSからDockerのlog-driver=awslogsがいけるようになっていた - Qiita
最近、Amazon ECSのコンソールに ECS now supports Docker 1.9 ... って出ます。 Dockerは1.9でlog-driverにAWSのCloudWatch Logsを指定できるようになった。 ただECSは1.7系だったので、しばらく次のようなプロバイダ逆転現象で使っていたんです。 さくらのクラウド(等)においてあるDocker-Machine: Dockerのlog-driverでawslogs指定。 => CloudWatch Logsとの連携楽ちん Amazon ECSで動かしているサービス: syslog経由でlogsコンテナからawslogsへ。 => 連携がなんかめんどっちい ベースAMIのDocker1.9への更新で、専用のlogsコンテナもういらなくなったはずだと思うので少し調べることにした。 ECSで使われるAMIからインスタンスを作成
AWS LambdaからAmazon Elasticsearch Serviceにリクエストを送る - Qiita
Amazon Elasticsearch ServiceはElasticsearchです。 普通にElasticsearchとしてエンドポイントを使用でき、アクセスポリシーは次の中から選びます。 Any 送信元IPアドレス IAM(STS) さて、ちょっと都合でS3に置かれたファイルを軽くパースしてElasticsearchに突っ込もうかと、IAMベースでLambdaからのリクエストを思ったところ、現状では署名リクエストを自前でつくって放り込むっぽい。 結果。やってはみたが、今は一旦CloudWatch Logsのストリームに流してからプリセットのファンクションを使うほうが結局楽に済みそう。ES用にboto3のresourceが実装されれば苦労しなくてよさそうだ。 とりあえず動いたのでコードをメモしておこう。 Elasticsearchドメイン側のポリシー IAMテンプレートでLambda
CircleCIでDockerデーモンのバージョンを変更する - Qiita
この記事時点でCircleCIのDockerは1.6.2のcircleciエディション(Docker version 1.6.2-circleci, build 2f3236d)が標準で動きます。 ただ、諸事情でもうすこし新しいDocker使いたいので差し替えの方法。 CircleCIがフォークしているDockerはこちらにありました。 circleci/docker バージョン差し替えのcircle.yml じゃあこれをビルドすればイイのかなーとgit cloneしてきた所、circle.ymlを発見。 machine: pre: - echo 'DOCKER_OPTS="-s btrfs -e lxc -D --userland-proxy=false"' | sudo tee -a /etc/default/docker - sudo curl -L -o /usr/bin/dock
東京リージョンS3でもAWS Lambdaしよう(SNS経由版) - Qiita
Lambda東京来ましたので、この記事はお役御免となりましたね。 Lambdaの使用例として、よくAmazon S3との連携を見ますが、S3でTokyoリージョンを選択しているとLambdaに通知できない。 さてS3の通知機能、Lambdaは出ないがSNSは出る。LambdaはSNSをSubscribeできる。じゃあ一旦そっち経由すっかと。 参考: Cross-Regionでやりたい時はクラスメソッドさんのこちらの記事で。 Amazon S3のCross-Region Replicationを使ってAWS Lambdaを発火させる ｜ Developers.IO S3 to Lambdaのイベント例 Lambdaテンプレートからそのまま拝借、S3のサンプルイベントはこうなっています。 { "Records": [ { "eventVersion": "2.0", "eventSource"
『AWSのCloudWatchで取得できるBillingの情報を毎日Slackに通知させて費用を常に把握する』 x 『AWS CLIの処理をAWS Data Pipelineで自動化する』 - Qiita
『AWSのCloudWatchで取得できるBillingの情報を毎日Slackに通知させて費用を常に把握する』 x 『AWS CLIの処理をAWS Data Pipelineで自動化する』AWSSlackDataPipeline 今日Webで見た記事が面白かった。これらです。 AWSのCloudWatchで取得できるBillingの情報を毎日Slackに通知させて費用を常に把握する - さよならインターネット AWS CLIの処理をAWS Data Pipelineで自動化する ｜ Developers.IO では合体させるぞ。 AWS Data Pipeline? 今回は変な使い方なので、この使い方に必要なポイントを。 起動するインスタンスはAmazon Linux 2013.03でした。 t1.micro(変更可)が起動して、処理が済んだらTerminate. スクリプトの事前確認はE
Loader.ioを使ってWordPressのバックエンド構成を変えつつ性能を測ってみる、php-fpmとHHVM - Qiita
同じインスタンスタイプだけども、処理数が倍違う。 WordPressの管理画面の記事一覧を表示 Loader.ioでも複数のリクエスト間でサーバレスポンスの値を使えます。WordPressはCookieが使えればいいみたいなので、次の2つ 管理画面ログイン (POST /wp-login.php ) 記事一覧表示 (GET /wp-admin/edit.php ) これならphpの処理系としての実力がさらに顕著に出るかも？ 厳密には1で返されるリダイレクト先(/wp-admin/)にもリクエストを送るようなので3回づつリクエストが発生していたけど、リダイレクト時にCookieは持ち回ってくれないみたい。 ツールにWordPressでログインの処理をさせる時は、Post用のパラメータとして次の項目を埋めればOKだった。 log : ユーザ名 pwd : パスワード wp-submit : L
CircleCIからAWS Elastic Beanstalkにpush(Deploy) - Qiita
こっちのほうがスマートなのでおすすめする。 > CircleCI経由でElasticBeanstalkにデプロイする方法 - Qiita ここの記事は参考程度に。 背景はさておき、PRをマージしたらさっさとElastic Beanstalkを更新しておいてもいいアプリもあるでしょう。 じゃあCircleCIからpushしておこう。 circle.yml circle.ymlはこんな感じ。 関連ツールのセットアップ＆キャッシュ、デプロイコマンドの組み合わせです。 --- dependencies: pre: - ci/01_eb_command.sh - ci/02_credencial_for_eb.sh cache_directories: - ~/awstools deployment: my_environment: branch: master commands: - git aw
Chefのローカルモードチュートリアル + knife-zero + knife-sakura - Qiita
前回 Chefのローカルモードだけでリモートサーバを運用してみようと、Knife-Zeroを作った。Nodeの構成情報もとれるよ。 - Qiita の続きといえば続きです。 Knife-Zeroのページはこちら。 http://knife-zero.github.io/ja/ Chef11.xからローカルモードというのが加わりました。Chef-Client/Server環境の簡易版であり、Soloの代わりでもあります。 Chef-Soloからの乗り換えとしてChef-Zero(ローカルモード)検索が多いようなので、この追記を先頭に移動 このサンプルではSSH越しにローカルモードを実行していますが、単にサーバ側にChef-Repoを置いてローカルモードをしたい場合、 Chefをインストール後にChef-Repoのディレクトリに移動してchef-client -zでOKです。 Soloみたいに
AWS MarketPlaceのCentOS公式イメージをいつものインスタンスっぽくしてPackerで保存 - Qiita
Amazon EC2でCentOSを使いたい場合、CentOSコミュニティがAWS MarketPlaceに公開しているイメージが一応ある。 かなり素の状態で置いてあり、例えば次のような点でAmazon Linuxなどと異なっている。 ログインユーザがroot ついでにランダムパスワード Iptables, Selinuxが有効 ec2metadataやawsコマンドがない (curlで取るのはOK) cloud-initが入ってない Packerで調整して保存 詳しくはこちら。 https://github.com/OpsRockin/centos6_ami_from_official これにより、次のように調整したAMIを作れる。 - Iptables, Selinux無効 ログインユーザはcloud-userに、sudo対応 Please login as the user "clo
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CircleCIがGithubに登録するデプロイキーを利用してコンテナ内のみで復号できる暗号を生成 - Qiita