LinuxでL4のロードバランサを簡単に作る手順 - Qiita
ロードバランサは高いので、Linuxで比較的簡単にL4の負荷分散を行えるLVSは使いドコロが色々あり結構便利。 久々に作った時のメモがわりとして、今回は、LVSの構築手順と簡単なテスト結果を順に書いてみた。 構成 ちょっと特殊な要件があり、負荷分散行うLVSも実際にレスポンス返すアプリも同じ筐体で動かしたいという前提で作った。 ※最初の投稿だと、同一筐体で動かした時にBACKUP STATEのLVSがARP応答する設定になっていたので、加筆！ LVS単体サーバとしても下記の手順で同じように作れる サーバはaa,bbの2台(vagrant上の仮想マシンとした) 同じ役割を持つサーバaa,bbをLVSを使って負荷分散したい LVS自身も冗長構成にして、aa,bbにやらせたい リクエスト元は、同一セグメントなのでDSR(Direct Server Return)を使う ※NATは、戻す時に直接L
インフラエンジニアじゃなくても押さえておきたいSSHの基礎知識 - Qiita
最近はクラウド上のサーバーを利用する事も多くなってきた。 サーバーの用意やネットワーク周りの設定はインフラ部門がやってくれるけど、アプリのデプロイ／設定は開発者がする事が多いので、開発メインでやってるエンジニアでも最低限SSHの知識は必要になる。 また、Vagrant等でローカル環境にVMを作成する事もあるので、ローカル環境内でSSHを使用するケースも増えてきた。 というわけでインフラエンジニアじゃなくてもSSHクライアントの知識は必須になってきているので、改めてSSHの再学習をしてみることにした。 SSHとは 暗号や認証の技術を利用して、安全にリモートコンピュータと通信するためのプロトコル。 SSHでは以下の点で従来のTelnetより安全な通信が行える。1 パスワードやデータを暗号化して通信する。 クライアントがサーバーに接続する時に、接続先が意図しないサーバーに誘導されていないか厳密に
systemd で CoreOS 上の Docker コンテナのログを集約・ルーティングする - Qiita
概要 CoreOS 上の全てのログをリモートサーバへ送る を応用し、systemd で起動した Docker コンテナのログをリモートサーバへ送る。 systemd で Docker コンテナを起動しておけば journalctl でログが取得でき、さらに systemd の unit のグルーピング（bind）機能を使ってログルーティングプロセスをバインドする。これは "coprocess" や "sidekick" というらしい。 ログの収集 コンテナのログ収集は systemctl を使ってコンテナを起動するだけでよい。そうすれば journalctl でログを見る事が出来るようになる # /etc/systemd/system/hello.service [Unit] Description=Hello After=hello.service Requires=docker.ser
ssh-agentの基本 - Qiita
説明するほどのでもない気がするけど、書いてとせがまれたので書いてみる。 適当に書いたので、細かい説明とか用語の使い方がおかしいのは大目に見てもらう方向で。 ssh-agentは、sshの鍵をssh-agentデーモン(?)に保持させておいて、使い回せるようにするツール。 使い方は、ssh-agentを起動して、そのシェル内でssh-add でkeyを追加するだけ。
一人React.js Advent Calendar 2014 - Qiita
React.jsについての基本的なところを書いていきます！ 公式読めばわかるようなことが多いですがReact.jsに興味をもつきっかけにでもなれば...。 v0.12.1で確認しています。 こっちは一人で書くように作ったものなので書きたい人はVirtualDOMに書くといいと思います。 (書く人がいなくて1人で書いているわけではない) この記事は古いので下記の更新情報も参考にしてください http://blog.koba04.com/post/2015/03/05/react-js-v013-changes/ http://blog.koba04.com/post/2015/09/22/react-js-v014-changes/ http://blog.koba04.com/post/2016/03/09/react-js-v15-changes/ http://blog.koba04.
Riot.js 2.0 を触ってみた — まだReactで消耗しているの? - Qiita
楽すぎてどうしよう。が最初の感触。まだ3時間しか触ってないけど、もうこれでいいや感が半端ない、深夜2時です。 Angularなのか、Reactなのか、2015年が明けても毎週のように新しいJSフレームワークが出る中で、もう正直どうでもよくなってませんか? でも、これは触って楽しいはず。 Riotって何? Riotは、公式ページに A REACT- LIKE, 2.5KB USER INTERFACE LIBRARY とあるように、Reactを意識して作られた超軽量のUIライブラリで、ビュー部分(コンポーネント)に特化しているのが特長です。Vue.jsとかとも同類です。Riot 1.0も「超軽量」という点で、一時注目を集めました。 そのRiotが、2.0で趣向を変えてJSX的なプリコンパイルの仕組みを取り入れて、ReactとPolymerのいいとこ取りのような感じになっています。ただし、次の
dockerをつかってrailsの開発をしてみる - Qiita
railsアプリをDocker化してみる - QiitaでアプリだけDocker化するのはさほど難しくないという話をした。 この場合はDBは既存のものが使えるから気軽に使えそうという話をした。 今回はDockerだけでRails開発をしてみようと思う。 HerokuのデフォルトがPostgreSQLなのでPostgreSQLを例にする。 Railsプロジェクトの作成 rails new をしよう。 docker run --rm -it -v "$(pwd)":/usr/src/app -w /usr/src/app rails rails new hello -d postgresql Dockerがインストールされていればrubyなんていらない。 Windowsでも戦えそうだが試してない。 夢が広がる。 しかし、rails rails newというのはなんだか格好悪い。 ちゃんとローカ
etcd総選挙を眺めてみる - Qiita
はじめに (2015/09/20追記) 初出時はv0.3.0くらいだったetcdも今の最新は2.2.0。起動時のオプションやAPIも非互換な形で変わってしまっているので、最新に合わせてお試し部分を少し修正。(@takiuchiさん、ご指摘ありがとうございます) etcdとRaft etcdはCoreOSで使われている軽量KVSで、Configurationなどの情報を複数のマシン間で共有できるようにする仕組みみたい。/etcに置かれた設定ファイルの置き換え的な意味合いで "etc" daemonなのかなと思ったが、語源を発見できず、もしかしたらぜんぜん違うかもしれない。 ともかく、etcdはKVSでありながら複数マシン間でのreplicationを実現している。まぁ、そんなKVSは沢山あるが、etcdで取っているアプローチがやや面白かったのでちょっと調べてみた。 まず、基本になる考え方が、
golangでSQLを叩くライブラリまとめ[基本/クエリビルダ/ORM] - Qiita
アプリケーションを作る上でデータベースを避けて通ることはできません。その中で最もポピュラーでパワフル(かつ普及している)のはSQLでしょう。 golangでも快適にSQLを操作したい。 このエントリでやること golangでSQLを操作する方法を、「基本(databse/sql)」から、SQLクエリを自動生成する「クエリジェネレータ」、最後に「ORM」という順序で解説します。 ライブラリの特徴などをいくつか抑えていくだけであって、網羅的ではない。雰囲気だけ。 操作方法 基本(database/sql) 標準ライブラリだけを使って頑張る。基本的にSQLを手書きして、変数とのマッピングも手で当てることになる。 sql.(*DB).Exec()を使うと、SQLクエリをそのまま叩ける。プリペアドステートメントはクエリのあとにガシガシ置いていくカンジ。 db, err := sql.Open("sq
![golangでSQLを叩くライブラリまとめ[基本/クエリビルダ/ORM] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/499bc39fe85486808061d02d400f949759592ae9/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9Z29sYW5nJUUzJTgxJUE3U1FMJUUzJTgyJTkyJUU1JThGJUE5JUUzJTgxJThGJUUzJTgzJUE5JUUzJTgyJUE0JUUzJTgzJTk2JUUzJTgzJUE5JUUzJTgzJUFBJUUzJTgxJUJFJUUzJTgxJUE4JUUzJTgyJTgxJTVCJUU1JTlGJUJBJUU2JTlDJUFDJTJGJUUzJTgyJUFGJUUzJTgyJUE4JUUzJTgzJUFBJUUzJTgzJTkzJUUzJTgzJUFCJUUzJTgzJTgwJTJGT1JNJTVEJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz0zMjUzNWI2MWMzMTVlODZjNjU1YTYzYTJhNmIxMmIwOA%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB1bWlzYW1hJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz03YWMyYWFiYzQ4ZGZlZWI2OWYxZmY5MDYyYTZjNGM5YQ%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-44OY44Oe44K_44Kk44OI%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3Dcd3c0601ae31cc0828e2549c83a17254)
Rails4の郵便番号/住所変換のマスターデータ作成手順 - Qiita
入力フォームにて郵便番号から続きの住所を自動入力させる際、 gemでは一部の住所で柔軟に対応できなさそうなので自前でデータを作りました。 郵便局のCSVデータの実際の加工方法・考慮した点と、Railsで使用する準備まで細かめに載せてみます。 前提 「○丁目」などの詳細住所パターンは、郵便番号の重複に関係なく全て削除する。 郵便番号の重複を許す。 同じ郵便番号で違う県にまたがるものもそのまま残す。 サービス開始時にseedからテーブルへの流し込みを行い通常更新はしない。 都道府県名はドロップダウン等でも使用しやすいよう別テーブルとする。 ＜表1. 作成テーブルイメージ＞ エリアテーブル 都道府県名テーブル
オレオレ /etc/default/docker の設定 - Qiita
はじめに 今年の4月にdocker meetup #2で、LTをさせて頂きました。 Docker地雷n本勝負 ※「docker 地雷」で検索すると一番上に出てきます笑 そこでもお話したのですが、自分の環境ではdockerのデフォルト設定ですと、ディスク容量などで何かと問題がありましたので、その解決策を書いておきます。 以下はdockerインストール後、自分が行う設定です。 環境 OS: ubuntu14.04 docker version: 1.4.1 # Docker Upstart and SysVinit configuration file # Customize location of Docker binary (especially for development testing). #DOCKER="/usr/local/bin/docker" # Use DOCKER_O
DockerコンテナをConsulで管理する方法 - Qiita
はじめに Dockerを利用するとコンテナをぽこぽこ沢山立てることが多いと思います。 コンテナが沢山できるので、それらに対していかに効率よくアクセス出来るかが肝になります。 またコンテナで提供するサービスのポートをホストに割り当てて利用する場合(-pオプションを利用する場合)、 ポコポコ出来るコンテナのポートを静的に(-p 80:8080みたいに)割り当てるのは面倒です。 なので動的に(-p 80みたいにしてホストの適当なポートに)割り当てたいところです。 ただし、動的に割り当てるとどのコンテナがどのポートでサービスを提供しているか把握するのが難しくなり、さらにマルチホストになるとどのホストで動いているかどうかを把握する必要もあり、これも難しいです。 この辺うまいこと出来ないかな、ということでServiceDiscoveryといったらConsulですよねってことで組み合わせて使ってみます。
2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 - Qiita
はじめに もうすっかり年末なので、これから2015年にかけてアプリケーションアーキテクチャがどのようになっていくのかという個人的な考え/妄想や背景について、「リアクティブ」というキーワードをもとににまとめてみたいと思います。 Google Trendsを見ると"reactive programming"という言葉は2010年前後から、ゆっくりとバズをし始め、現在も上昇を続けています。 また、仕事としては、2010年ごろから大規模なWebサービス開発において、フロントエンド、バックエンド、アルゴリズム改善といった様々な箇所で、リアクティブプログラミングの要素を取り入れながら、アーキテクチャの改善を進めてきました。そのため、こういったアーキテクチャがコード品質の維持や安定性の向上、実際的で複雑な問題の解決にも適応可能であるということを実感として持っています。 近年、そういった要素が様々なツール
MVCの流れを簡単にまとめてみる - Qiita [キータ]
理解しやすいように適当に遮ったり、言い切ってしまったところもあるがご容赦いただきたい。 MVCの登場 MVCは、SmalltalkのGUIライブラリのモデルとして登場した。 これはGUIアプリケーションを記述する際に、適切なモデル化を進めるのにとてもいい考え方だと思われていたし、実際にそうだった。 これはアーキテクチャパターンとして、それぞれがどのように依存するべきか、どこにコードを書くべきかということを端的に表している。 安定依存の原則というものがある。これは、要件が安定しているモジュールに依存し、要件が変動しやすいモジュールには依存しないようにするという原則だ。MVCアーキテクチャでは、GUIアプリケーションの安定関係をModel > View > Controllerの順でとらえている。データ処理や業務要件というのは安定しており、UIパーツもまた比較的安定している。それらを統合してア
![MVCの流れを簡単にまとめてみる - Qiita [キータ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/4eab66c03020ced4619e83c8ebe5ff0c4cbcd864/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9TVZDJUUzJTgxJUFFJUU2JUI1JTgxJUUzJTgyJThDJUUzJTgyJTkyJUU3JUIwJUExJUU1JThEJTk4JUUzJTgxJUFCJUUzJTgxJUJFJUUzJTgxJUE4JUUzJTgyJTgxJUUzJTgxJUE2JUUzJTgxJUJGJUUzJTgyJThCJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1hNWRhZWZkYmY5ODQxZTI1ZWE2NjFjZGEzYjVjNmRmNA%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwaGlyb2tpZGFpY2hpJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz00MmViZmQ0YmEwMzUxYTZmMGQyZjFhNWVhNzIyYjI2MA%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D02e229a1404969c8e3f437e0d6b7bbe0)
本気で使う Docker - Qiita
Docker Advent Calendar 2014 12/25 の記事、本気で使う Docker です。 ということで、実際に弊社で Docker を使った運用を開始した際にはまったところや、悩んだ所、どういう風に使っているのかについてぱらぱらっと書こうと思います。 "本気" なぜ Docker を使うのか、というと、僕の中では以下のような理由があります。 すべてのアプリケーションを(インフラ的に)同じ方法でデプロイ、管理したい 特定のサーバー / インスタンスの状況に依存することなく、アプリケーションの依存とインフラ都合の依存を別管理したい Docker なんかかっこいいっぽいし使ってみたい 上記のような都合から、どうやって作っていくかを考えていきます。基本的には1番目と2番目の理由が重要です。 Docker コンテナのいいところ とある Rails アプリケーションをデプロイするた
仮売上（オーソリ）とユーザ体験 - Qiita
更新のおしらせ 本記事はWebPay gemのバージョン2系に即して記述しています。 その後、メジャーバージョンアップを行ったため、メソッド名やエラー名などが変更になっています。 最新の情報はWebPay公式サイトのRuby APIドキュメントを参照してください。 ユーザのがっかりを無くす 昨日のwebpay - 仮売上（オーソリ）を使ったサービス設計 - Qiita [キータ]を少し具体的なところに落として、活用する方法を探ってみます。 例えば、AmazonなどECサイトでの買い物を思い浮かべてみましょう。 購入の最終確認画面まで辿り着き、無事に購入処理を終えて後は商品を待つだけという気分になり離脱した後にメールで「クレジットカードの情報を修正して下さい」はなかなか辛い思いをするのではないでしょうか。 ECサイトには、カードが何故使えなかったかの明確な理由が必ずしも得られるわけではない（
[Swift 1.1] swiftで api を叩いて、JSONをパースして、表示させる方法 (xcodeは6.1, iOSは8.1) - Qiita
[Swift 1.1] swiftで api を叩いて、JSONをパースして、表示させる方法 (xcodeは6.1, iOSは8.1)XcodeiOSSwift 対応バージョン swift 1.1 xcode 6.1 iOS 8.1 目標 「yahooニュースのRSSをJSONで配ってるapiを叩いて、JSONデータをゲトして、テーブルでひ項目表示させて、セルをタップしたらwebViewで元記事が見れる」ところまで実装。 Playgroundでやってみました。 import UIKit import XCPlayground //make URL of google feed api var urlString = "http://ajax.googleapis.com/ajax/services/feed/load?v=1.0&q=http://rss.itmedia.co.jp/rss
![[Swift 1.1] swiftで api を叩いて、JSONをパースして、表示させる方法 (xcodeは6.1, iOSは8.1) - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/044d3cd8c8d2713422f82d8b6e0415a65a6e6378/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCU3dpZnQlMjAxLjElNUQlMjBzd2lmdCVFMyU4MSVBNyUyMGFwaSUyMCVFMyU4MiU5MiVFNSU4RiVBOSVFMyU4MSU4NCVFMyU4MSVBNiVFMyU4MCU4MUpTT04lRTMlODIlOTIlRTMlODMlOTElRTMlODMlQkMlRTMlODIlQjklRTMlODElOTclRTMlODElQTYlRTMlODAlODElRTglQTElQTglRTclQTQlQkElRTMlODElOTUlRTMlODElOUIlRTMlODIlOEIlRTYlOTYlQjklRTYlQjMlOTUlMjAlMjh4Y29kZSVFMyU4MSVBRjYuMSUyQyUyMGlPUyVFMyU4MSVBRjguMSUyOSZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9MjAzYjhlMzYxYjY5NDVkNjIyZWY1YTdiZjdlODg2Zjg%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBjb2xvcnJhYmJpdCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9NzVkYWE3NzRhZDk0NGI5OWZhN2I0OThhNWQwNWUxNDI%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D37cb006aa0662e297556fdc1231a37a9)
iOSアプリの設計でBaseViewControllerのようなのは作りたくない - Qiita
結論 小手先で楽をするためのボトムアップな設計は後々苦労する 継承を使った差分プログラミングは長年運用していくと大変だ 人は楽な方に流れるので、Baseクラスで解決すべきでない問題をBaseクラスで解決して後で困る はじめに この文章は2015年1月のpotatotips13で発表するネタ用のメモに書いてました。 実際に発表した内容を含む様子は下記のページにまとめています。 http://curiosity.co.jp/potatotips13/ 会場で質問されたりツイートの様子を見てて気づいたのですが、BaseViewControllerを使いたくないという"この文章"と同意の意見は、比較的経験のあるおじさんたちの意見であって、若い人からするとなぜBaseViewControllerを使ってはいけないように言われるのかについて具体例を聞きたがる傾向が強いです。 また、不必要に自分が気に入
Basic認証とOAuth - Qiita
Basic認証とOAuthとその辺の情報について整理しておく。OAuthや認証・認可について説明しようとすると、1文字記述するたびに誤りが含まれてしまう可能性があるので、本当に緊張感を持って記述しなければならない。それでもなお、この文章にはたくさんの誤りが含まれている。 UsernameとPasswordを受け取って認証する形式の認証方法。UsernameにはEmailを使うこともある (要は全ユーザの中で一意なことが保証されていてかつ他の人がその値を知っていても特に問題がないという情報であればOK)。Passwordは本人しか知り得ない情報。 OAuthという仕様に則って提供される認可方法。古いOAuth 1.0と、OAuth 1.0の複雑なところなどを改善したOAuth 2.0がある。一般的にはOAuth 2.0を使うことが多いが、例えば幾つかのサービスの提供している認可方法はOAut
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
絶対ハマる、不思議なnil - Qiita
