no ramen, no life?


title: "no ramen, no life?" date: 2019-12-15T22:08:24+0900

draft: false

なんでまたRamen?

この記事はBBSakuraNetworks Advent Calendar 2019のものです。これまで非常に高尚な内容で推移してきましたが、いきなり私がレベルを下げたいと思います^^;

なんでまた"no ramen, no life"なのか?「えっ福智さん、そんなにラーメン好きだっけ?」と言う声が聞こえそうです。はい確かに私はラーメンよりワインですし最近はワインより日本酒だったりもします。

「じゃー何でラーメン?」 これはCloudFlareのTom Pasekaさんの影響が大きいです。彼と香港で食べたButaoのラーメンが美味しかった!それ以降、彼と海外のイベントで会うとラーメンを食べるようになりました。いつしかその「麺会」はRamen BoFとなりFacebookページに発展していきました(現在メンバー数146人!)。BBIXのモットーは"no peering, no internet"なのは前回お話しましたが、それに掛けてここでのモットーは"no ramen, no life"としました。今ではTomが悪ノリしてロゴマークは作るはステッカーにするは挙げ句の果てにはバッチまで作る!もっとノリが良すぎるのがBBIXというか私でついにBBIXノベルティーカップラーメンのラッピングで"no peering, no internet"と"no ramen, no life"の両方を載せるという馬鹿技に走ってしまいました^^; ただ海外のお客さんの評判はめちゃ高くAwesome!の連続です。私も調子にのって"My company slogan is "no peering, no internet" but my life slogan is "no ramen, no life!"というとウケがいいです。英語も日本語もリズムが大事なのでそう意味でも良いと思いますがね^^;

それ以降、海外出張をするたびほぼ毎回現地でラーメンを食し、FBにno ramen, no life in XXXと上げています。過去49件の海外のラーメン屋さんを訪れていますが今回はその中での「海外ラーメンベスト5」をご紹介したいと思います。

(Ramen BoFの様子)

(Tom Pasekaさんと"no ramen, no life")

海外ラーメン勝手にランキング

No.5 Menya Ramen Denver (https://www.menyacolorado.com/)

このお店はNANOG73 inDenverの時に寄ったラーメン屋さん。アメリカに限らず海外のラーメン屋さんはスープはそこそこですが麺がちゃんと作れません。何でも材料の仕入れが難しく日本のような製麺ができないとか。その中においてこのMenyaさんのラーメンは麺も及第点。スープもおいしい。あとDenverという街がお気に入りというのもTop5入りした要因かも^^;

No.4 Kanadaya London (https://www.kanada-ya.com/)

金田屋という元々福岡の行橋にあったラーメン屋のロンドン店。大英博物館の近くにありいつも行列が外まで伸びています。この近くには一風堂のロンドン店もありロンドンではラーメン銀座かもです。あっさりしたスープながらしっかりコクもある。博多で人気な理由が分かりますし、ロンドンっ子を虜にしているわけですね。

No.3 Butao in Causeway Bay HongKong (https://www.butaoramen.com/)

ここは前出のCloudflareのTomの紹介で行ったお店です。Peering Asia2.0 in Hong KongでのRamenBoFもここで行いました。渋谷にあるラーメン凪 豚王が本店であり、香港はその分家のような存在だと思います。渋谷本店と香港の店舗の比較をしているWebがありましたので載せておきますね。( https://gigazine.net/news/20140926-butao-ramen/ )私の感覚もこのWebと同じく日本人には少し濃い目でRichな味がします。ただTomはいつもここでMore Richにして物凄くこってりを追求します。また彼に言わせると香港でもCauseway BayよりCentralのお店の方が美味しいらしいです。私にはその違いはあまり分かりませんでしたが。。。

No.2 Kaminari Tonkotsu RAMEN Mexico City (https://www.facebook.com/Kaminaritonkotsu/)

先日行ったばかりのお店です。店のたたずまいも「大丈夫かな?」と言う感じでしたがひとつひとつ丁寧に作られていて美味しかったです。麺も期待以上の出来であったと思いますし、なぜかバランスがよかったと言う印象です。

No.1 Kodawari Yokocho Ramen in Paris (https://www.kodawari-ramen.com/)

私が何と言っても絶対にNo.1にあげるお店がKodawari Yokocho Ramanのパリにあるお店です。ルーブル美術館の近くにあるお店ですがかなり有名らしくいつも行列が出来ているようです。このお店のいいところは何と言っても麺がおいしい。おそらく海外で食べるラーメンで麺が一番おいしい。何でも日本で修行した確かバングラデシュのラーメンシェフがこのラーメン屋を作るのに製麺機まで購入しパリに運び、この店の地下室で「こだわりの麺」を作っているそうです。内装も昭和時代を思わせるイメージで新横浜・ラーメン博物館と同じテイストに仕上げるという「こだわり」です。なのでお店の名前も"Kodawari"なんでしょうね。パリにいって日本食が恋しくなったら絶対におすすめのラーメン屋さんです。

番外編 Yui Dubai (https://selectshopframe.com/pages/about-yui)

番外編で取り上げたいのがYui Dubai。なんと中東のDubaiにあるラーメンが食べれるお店。といっても流石にイスラム国家ですから"Tonkotsu"なんてありません。ただそれ抜きで美味しいラーメンを一生懸命考えて作っていると思います。味のトータル点数は流石に上位のお店を凌駕することはできませんが、中東にいってラーメンが恋しくなったら行く価値はあると思います。

まとめ

この活動?を通じていつも思うことなんですが、中国生まれのラーメンですが間違いなく日本育ち。そして世界中のPeering GuysがRamen大好き。RamenBofで皆んなで食べるときは本当にいい笑顔。次はHawaiiのPTCでのRamenBofかな?「情報革命で人々を幸せに」ならぬ「ラーメンで人々を幸せに!」。。。なんの会社かわからなくなってきました^^;

セキュアなリバースプロキシの作り方

こんにちは

この記事は BBSakura Networksのアドベントカレンダー 14日目です。

在宅などのリモートでの働き方が増えてくると、困ることの一つに社内のシステムへのアクセスをどうやってセキュアに行うかがあります。クラウドのサービスであれば2段階認証などが提供されていますが、私のようなエンジニアが社内のサーバに立てたツール等は、社内のLANからのみアクセス許可することでセキュリティを保ってる場合も多いと思います。このようなシステムへのリモートアクセスをセキュアにするために、Oauth2による認証連携とクライアント証明書によるアクセス制限が行えるリバースプロキシ の立て方を紹介したいと思います。同様なことは、検索してくだくといろ色々なサイト紹介されていることも多いと思いますが自分用のメモもかねて記事にしたいと思います!

環境

リバースプロキシは ubuntu 上でdockerを使って構築しています。

構築手順

0. 概略

Internet --- reverseproxy(https://reverseproxy.example.co.jp) --- 社内システム(http://10.10.10.10)

oaut2_proxy と連携する oauth2 provider は、oauth2_proxy の default でもある google を使用しています。

1. docker/docker-composeのインストール

 sudo apt install curl
 curl -fsSL get.docker.com | sudo sh
 sudo curl -L "https://github.com/docker/compose/releases/download/1.25.0/docker-compose-(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
 sudo chmod +x /usr/local/bin/docker-compose

2. 用意したファイルとディレクト

reverseproxy/
|-- CA
|-- default.conf
|-- docker-compose.yml
`-- Dockerfile

3. ディレクトリ作成

mkdir reverseproxy
mkdir reverseproxy/CA

4. docker-compose.yml

docker-compose.yml は下記の内容でファイルを作成してくだい。

version: '3'
services:
  reverseproxy:
    build: "."
    image: "reverseproxy"
    container_name: "reverseproxy"
    ports:
      - "443:443"
    volumes:
      - ./default.conf:/etc/nginx/conf.d/default.conf
      - /etc/letsencrypt/live/reverseproxy.example.co.jp/privkey.pem:/etc/ssl/private/server.key
      - /etc/letsencrypt/live/reverseproxy.example.co.jp/fullchain.pem:/etc/ssl/certs/server.crt
      - ./CA:/etc/ssl/demoCA
    depends_on:
      - oauth2_proxy
  oauth2_proxy:
    image: "quay.io/pusher/oauth2_proxy:v3.1.0"
    container_name: "oauth2_proxy"
    command: >
      --http-address=0.0.0.0:4180
      --redirect-url=https://reverseproxy.example.co.jp/oauth2/callback
      --cookie-secret=example.co.jp
      --client-id=XXXXXXXXXXXX.apps.googleusercontent.com
      --client-secret=XXXXXXXXXXXX
      --upstream=http://10.10.10.10/
      --email-domain=example.co.jp

reverseproxy のサーバ証明書は、Let's Encrypt で作成したののをdockerのnginxでも使用しています。
Google のクライアントキーとシークレットは Google Developers Console から取得しています。

5. Dockerfile

クライアント証明書を作成するために opensssl をインストールした nginx のイメージを作成するための Dockerfile です。

FROM nginx

RUN apt update && apt install openssl

EXPOSE 443
CMD ["nginx", "-g", "daemon off;"]

6. default.conf

nginx の設定ファイルです。初回立ち上げ時は、CA局の証明書がないため ssl_client_certificatesl_verify_client はコメントにしておきます。

server {
    listen 443 ssl;
    server_name  localhost;
    server_name reverseproxy.example.co.jp;

    ssl_certificate     /etc/ssl/certs/server.crt;
    ssl_certificate_key /etc//ssl/private/server.key;

    #ssl_client_certificate /etc/ssl/demoCA/ca.crt;
    #ssl_verify_client on;

    location / {
        proxy_pass http://oauth2_proxy:4180;
    }

    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }
}

7. docker 立ち上げ

sudo docker-compose build reverseproxy
sudo docker-compose up -d

8. クライアント証明書作成

問題なく docker のコンテナが起動したら、次はクライアント証明書を作成します

8.1 クライアント証明書作成

reverseproxy コンテナに bash でアクセスし、openssl を使ってクライアント証明書を作成します。

sudo docker-compose exec reverseproxy bash

以下は、reverseproxy コンテナの中で実行します。

CA局の証明書作成
cd /etc/ssl/demoCA
openssl genrsa -out ca.key 2048
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt -subj "/C=JP/ST=Tokyo/L=Shinjuku-ku/O=Example/OU=Development/CN=reverseproxy.example.co.jp/emailAddress=admin@example.co.jp"

cd /etc/ssl
openssl ca -name CA_default -gencrl -keyfile ./demoCA/ca.key -cert ./demoCA/ca.crt -out ./demoCA/ca.crl -crldays 3650

touch demoCA/index.txt
echo '01' > demoCA/crlnumber

CA局 の Common Name(CN) には、リバースプロキシの FQDN を指定します。

クライアント証明書作成
cd /etc/ssl
openssl genrsa -out ./demoCA/user01.key 2048
openssl req -new -key ./demoCA/user01.key -out ./demoCA/user01.csr -subj "/C=JP/ST=Tokyo/L=Shinjuku-ku/O=Example/OU=Development/CN=user01/emailAddress=admin@example.co.jp"
openssl x509 -req -days 365 -in ./demoCA/user01.csr -CA ./demoCA/ca.crt -CAkey ./demoCA/ca.key -CAcreateserial -CAserial ./demoCA/ca.seq -out ./demoCA/user01.crt

クライアント証明書 の Common Name(CN) には、ユーザ名(上記例では user01 )を指定します。 作成された証明書を PKCS12 形式に変更します。

openssl pkcs12 -export -clcerts -in ./demoCA/user01.crt -inkey ./demoCA/user01.key -out ./demoCA/user01.p12v
exit

コンテナ中での作業はここまでで、'./reverseproxy/CA/user01.p12' のファイルを Windows や Mac にインストールすればクライアント側の準備は完了です。

NGINXの再起動

サーバ側の証明書も作成し終えたので、最初にコメントした NGINX の ssl_client関連のコンフィグのコメントを外し, コンテナを再起動します。

reverseproxy/default.conf を編集

ssl_client_certificate /etc/ssl/demoCA/ca.crt;
ssl_verify_client on;
````

コンテナの再起動

sudo docker-compose restart reverseproxy ````

以上です。

BBSakura Networks Blogで使っている技術

※この記事の内容は古くなっております。現在は はてなブログ for DevBlog を使っています。

こんにちは。BBSakura Networksの日下部(@higebu)です。 この記事はBBSakura Networkのアドベントカレンダー 11日目として書きました。

昨日は佐々木社長による Peeringの世界とインターネット でした。

今更ですが、BBSakura Networks Blogを作ったので、特にすごい技術を使っているわけではないのですが、使っている技術について簡単に紹介したいと思います。

ちなみに、作った理由は、個人のSNSなどのアカウントと仕事を結びつけたくなかったり、そもそもブログを書いていないような人でもアドベントカレンダーに参加しやすくするためです。

Hugo

開発運用しているプロダクトではGoを使っていることが多いのと、使っている人が多いので、これにしました。 今確認したところGitHubのスター数が40036でした。

テーマはシンプルなものを探していたところ、 inkblotty が良さそうだったので、これをベースにロゴなどいくつかの修正をしたものを使っています。 余裕があれば独自のデザインにしたいという気持ちはあります。

コンテンツはMarkdownで書かなかればならず、gitも使えないといけないですが、弊社では社長もMarkdownで記事を書き、gitコマンドで記事を公開しています。

GitHub Pages/GitHub Actions

このブログはURLでわかる通り、 GitHub Pages でホストしています。 また、公開は GitHub Actions で自動化しています。 ブランチとしてはMarkdownで書いた記事や画像ファイルのための source ブランチと、Hugoによって生成されたコンテンツのための master ブランチがあり、 master ブランチのコンテンツはGitHub Actionsで自動で更新されます。 実際のworkflowは下記のようになっています。

name: github pages

on:
  push:
    branches:
    - source

jobs:
  build-deploy:
    runs-on: ubuntu-18.04
    steps:
    - uses: actions/checkout@v1
      with:
        submodules: true

    - name: Setup Hugo
      uses: peaceiris/actions-hugo@v2
      with:
        hugo-version: '0.60.1'
        extended: true

    - name: Build
      run: hugo --minify

    - name: Deploy
      uses: peaceiris/actions-gh-pages@v2
      env:
        ACTIONS_DEPLOY_KEY: ${{ secrets.ACTIONS_DEPLOY_KEY }}
        PUBLISH_BRANCH: master
        PUBLISH_DIR: ./public

見て分かる通り、 https://github.com/peaceiris/actions-hugopeaceiris/actions-gh-pages を使っているだけであり、非常にシンプルです。 これらのActionを開発してくれている、 @peaceiris さんには大変感謝しております。 Actionの使い方についての解説はご本人による解説が GitHub Actions による GitHub Pages への自動デプロイ にありますので、割愛します。

以上です。

Peeringの世界とインターネット

改めまして、こんにちは。BBSakura Networks社長の佐々木です。 この記事はBBSakura Networkのアドベントカレンダー 10日目です! 今日はインターネットのバックボーンについて焦点を当てて話をしたいと思います。

インターネットとは?

インターネット@Wikipediaとは「インターネット(英: the Internetあるいは英: internet)とは、インターネット・プロトコル・スイートを使用し、複数のコンピュータネットワークを相互接続した、グローバルなネットワーク(地球規模の情報通信網)のことである。」とWikipediaに書かれているようにIPを用いたコンピューターネットワークを相互接続しあったものになります。

相互接続の方法と種類(Peering vs Transit)

インターネットにおけるネットワーク同士は通常BGPというプロトコルで接続され、AS番号という番号をもってネットワークを識別しております。会社名の代わりに2914(NTT Communications)、2516(KDDI)、17676(SoftBank)という具合にAS番号で会話をするのが業界通な人間です。 このAS同士を接続すること(BGP Peerを上げること)をPeeringと言います。 BGPでは自分の経路情報(自網に向けて流してもいいIPアドレスの集まり=IP Prefix)を相手に広報し、経路情報を受けている経路の中で一番効率的(に見える)なルートに対してパケットを送信します。相手からの情報を信用してトラフィックを送るところは相互信頼の元に接続がなりたつ、インターネットの原点そのものではないのかと思います。(偶に他人の設定ミスで通信障害が起きてしまうことがあります。)

インターネットの相互接続は大きく分けて2つあり、Peering(自ASの経路のみを交換する)もしくはTransit(一般的にはInternet全体への経路=Full Routeの経路を交換し、当該ASを経由してインターネットへの接続を提供)があります。 PeeringにはIXを介したPublic Peerと直接ルーター同士を1:1で繋いだPrivate Peeringがあります。

Peeringはお互いのビジネスメリットを元に成り立っております。 コンテンツの人たちはユーザーに近いISPと直に繋がることで障害ポイント(Transit プロバイダ)を減らし、ISPの人たちはコンテンツと直に繋がることで同様に品質の向上(遅延の低減)やコスト削減を実現しております。

Peering交渉について

インターネットは相互接続で成り立っておりますので、Peeringなしには成り立ちません。 Peeringの世界は大変おくゆかしい世界で、世界中のネットワークエンジニア(AS持ってる会社のルーター管理者)があーだこーだ理由をつけて、お酒を飲むためにオフラインで集まり、BGP Sessionをあげる交渉をし、お互いのネットワーク経路を交換します。オンラインでは断るにも「No」とメールで返信するだけですが、オフラインコミュニケーションをする事で、断る行為に対するハードルを上げている訳です。 オフラインのPeeringイベントは毎年たくさん開催されており、例えば以下のような物があります。 - Peering BoF (JANOGInternet Weekとかの陰で開催されてます。) - IXのユーザーを集めたイベント(JPIXさん、インターネットマルチフィードさん、BBIXで各社年2回ずつぐらいやってます。) - APRICOT (APNIC主催のアジアのインターネットイベントです。次はオーストラリア!) - Global Peering Forum (北米で開催されるPeering Forum) - Peering Asia (日本のIX事業者で始めたアジア事業者の為のPeering Forumです) - European Peering Forum (ヨーロッパで開催されるPeering Forum) - その他、 ISOCのEvents Calendar見るとたくさんあります 

このように、ネットワークエンジニアはインターネットを支えるために世界中の観光地で毎年楽しくPeering交渉をしているわけです。 他にもPeering in JapanというSlackや、Peering in JapanのWebsite等で日々情報交換を行ってます。

物理の世界

Peeringの話ばかりになってきたので、物理の世界(Layer 1)の世界の話をしたいと思います。 我々インフラエンジニアにとっては、やはり論理よりも物理的な接続の世界が一番興味深いのではないかと思います。 最近では事業者間の相互接続については、10Gbpsや100GbpsのEthernetで接続するのが一般的です。 ネットワークPOPと呼ばれるようなネットワークが集まったDCに外部接続用のルーターを置き、そこでIXやPNI(Private Network Interconnection)をする事が多いです。

ネットワークPOPと自網の間はキャリアの専用線光ファイバーを使って接続します。 キャリアの専用線サービスでは一般的にWDMという装置を使い、ファイバーの中で複数の回線(波長)を多重化しております。国境や島をまたがる部分では海底ケーブルを使って接続します。日米間などでは8000kmを超える距離のケーブルが引かれており、房総半島からアメリカ西海岸や東南アジアまでケーブルが伸びているというのは考えるだけでも大変ロマンのある話でございます。ですので、我々のようなインフラエンジニアはみなさん定期的にこういったインフラを観察をしに行くことを趣味とする人間も多く、うちの社員のようにそういったロマンあふれるインフラの写真集を作る人もいます。

主要な海底ケーブルはTele GeographyのSubmarine Cable Mapに掲載されており、通勤時などの暇な時間に偶にiPadなどで眺めるのがインフラエンジニアの嗜みとなります。 ここを見るとよく分かりますが、実は日本は北米とアジアの玄関口になってます。 BBIXではこの地の利を生かして、海底ケーブルの陸揚げ局にノードを設置し、アジアと北米の架け橋のようなHubになることを目指してます。

東日本大震災で日米間のケーブルが多く被災してから日本を経由しないケーブルが増えましたが、まだまだアメリカとアジアの通信で日本を経由する通信が大半を占めていることが想定されてます。イチ日本国民としてこの地政学的な優位性を元に、日本がアジアのHubのような環境になっていけば良いなと思ってます。 (その為には電気代の高さやいろいろな規制の動きなどへ注意を払うことが重要だと思います。)

BBIXのこれまでと今後、そしてBBSakuraへの思い

強い大人?

この記事はBBSakura Networksのアドベントカレンダーの記事となります。内部のエンジニアから「m-fukuchiのような強い大人にも書いて欲しい」とつぶらな瞳で言われた気がしたので頑張って書きたいと思います。 「強い大人」と言われてもなぁー そんな強そうに見えるのかなぁー 以前BBIXの某女子社員との会話で「BBIXって動物園みたいだね。そうすると私は動物園の園長さんかな?」と聞いたところ「いいえ、福智さんはライオンです。まわりをゆっくり歩きながら たまに「ガオォー」って吠えるじゃないですか?」と言われてなるほどなーそう言うイメージなんだと思いました。なのでそういう意味でも「強そう」に見えるのかもしれません。が、実際は心配性のところもあり意外とマメなところもあり、実は典型的なA型人間です。そんなおじさんですがBBIXのこれまでと今後、そしてBBSakura Networks(以下BBS)への想いをつらつら書いてみたいと思います。しかし、これまでのアドベントの記事をみていて若手の圧倒的なドキュメント能力というか。。。とてもとても圧倒されています。本当に素晴らしいことでこれだけでもBBSをつくってよかったなー、さくらインターネットさんとの異文化交流は本当に意味があるなと思いました。

田中さんとの出会い

BBIXの話をする前に、私がこの業界に入ったころから遡りたいと思います。私は現在も原籍所属会社はソフトバンク株式会社となっておりこの会社に入社したのは2000年2月となります。ですので来年の2月で丸20年となるわけです。きっかけは1999年9月から当時のソフトバンク東京電力マイクロソフト・ヤフーが共同で立ち上げた「スピードネット」と言う会社に出向したことから始まります。スピードネット自体は最終的には東京電力の会社として一時期継続されましたが、ソフトバンク側はソフトバンクネットワークスという会社を立ち上げこれが所謂中間持株会社の役割を果たし、その配下にソフトバンクとしては初の第一種通信事業者であるIPRevolution(以下IPR)という事業会社を設立。私はそのIPRの技術系社員第1号で文字通り立ち上げを行いました。IPRは法人向けブロードバンド・ISPで、当時一般的な1.5Mbpsの専用線を利用した法人インターネット回線が月額30-40万円程度していたのを、100Mbps・アドレス空間/26で月額19.8万円で提供するというサービスをやっていました。これは2001年よりNTT東西により開始された加入者ダークファイバー解放により コストモデルのビックチェンジが起こり実現できたサービスでした。当時としてはかなり画期的だったので新しい物好きのエンタープライズユーザーには好評でした。特にゲーム会社が何本も回線を引いてくれたのを覚えています。

AS番号は10007。結構いい数字で気に入っていたんですが、当然JPIXに接続してPeering交渉も私がやっておりました。そのとき出会ったのが当時エスアールエスさくらインターネットで副社長をされていた田中さんでした。今はもうなくなりましたが大阪・心斎橋のソニータワー近くで待ち合わせをし、そのまま近くのお好み焼き屋で食事をしたのを覚えています。田中さん24歳。私は34歳。当時の田中さんの印象は、皆さんご存知のとおり筋金入りのコンピューター大好き・インターネット大好き人間ですので「若いのにすごいなー」というのが第一印象ですが、私の実家が当時のさくらインターネット本社ととても近かったことと当然私も関西人ですので、何かかんやといろんな話で盛り上がったのを思い出します。今もたまに二人で食事をしますがその時と今とあまり雰囲気は変わらず兎に角一緒に喋って楽しいし、時間があっという間に過ぎてしまいます。

(写真は当時の心斎橋ソニータワー)

BBIXの誕生

2003年5月

私はその後2003年1月に当時のソフトバンク事業会社4社が合併してできたソフトバンクBBに合流し以降Yahoo!BB のネットワーク運用の責任者となりインターネットに関わってきましたが、その時に現在のソフトバンク常務でありチーフサイエンティストの筒井さんが「YBBが円滑にPeeringが出来るIXをJPIXと同じように作るべきだ!」と言い出したのがきっかけでBBIXが2003年5月に誕生します。私はNW運用の責任者でもありPeering交渉では大手事業者を担当していたこともあったのでBBIXの社外取締役として就任いたしました。

当時はJPIXさんが商用IXとしては唯一のIXであったので、BBIXとしてお客さんを呼び入れるためには。。。。悪知恵働きました。。。^^; JPIXさんをDePeerしてBBIXのみでPeeringを行おう!と私が言い出しJPIXさんを脱退しました。このDePeer事件以降いくつかのISPさんやコンテンツ事業者さんがBBIXに接続に来てれましたが、当然Y!BBの為だけに接続してくれるISPはそんなに多くなくある程度の効果はあったものの、それ以上の大きな伸びはありませんでした。以降JPIXさんやJPNAPさんとは大きな差があるまま低迷した時期を過ごします。ただソフトバンクBBの接続回線が相当量あったので会社としての継続は細々と行なっておりました。

ソフトバンクweb 経営陣ファイル 2005年通信革命を支えたCTOの横顔より 筒井さん)

2012年5月

その後、いろんな経緯があって私は一旦NW運用を離れます。そんな折 現在のソフトバンクCTOの宮川さんより「お前、BBIXに専念してビジネスとしてBBIXを成長させてみろ!」という直撃弾が降ります。2012年5月私は現在の専務取締役 兼 COOに就任。BBIXをどうやって盛り上げていくかというテーマに立ち向かいます。当時お客さんの数で10数社程度、ピークトラヒックで18Gbps程度でした。本当にYBBの経路を取りたいお客様しかいない状態でJPIXさんやJPNAPさんとは大きな差がありました。

LCCIX?

当時営業を担当していたのが現在のソフトバンク常務の藤長さんで、彼が言い出したのが「航空業界でのJALANAのような大手航空会社に対抗し低価格のLCCが台頭してきた。もしBBIXがユーザーを呼び込むのであればJALANAの値段ではなくLCCのような気軽な値段で接続できるIXを目指すべきだ」と。聞いた瞬間はそんなに安売りしても接続してくれるかどうかわからないし、、、と言う感想でしたが検討は開始しました。状況が変わったのは2012年1月のJANOG29 in Wakayama で現在Googleにいる川村さんがPeering in Japanというセッションの中で「今のポート料金に満足していますか?」という問いかけをされました。当社は既に低価格提供を検討していたわけですが私自身は何も発言せず、JPIXの石田社長(当時)とJPNAPの外山副社長が品質維持のためにはこの値段は必要なんだと説明されていました。当時の10G portの値段は月額200万円程度。当社も定価は260万円でした。

 Peering in Japanの発表の後有志が集まりPeeringのあるべき姿について議論されていたわけですがポート料金の低廉化については自分たちでIXを運用することも視野に入れて検討されていましたが結局のところサービス提供の責任主体をどのようにするのかで結論に至らずと聞いています。そこへ我々が欧米並みのポート料金で提供する新しいサービスBBIX IXコネクトライト10Gを月額22.8万円で行うと言うアイデアを川村さんに説明しました。彼の第一声が「まぁーーーじですか!」と大変驚かれたのを覚えています。

(東洋経済オンラインより)

(JANOG29 Wakayama Peering in Japan 資料より)

ソフトバンク・イノベンチャー

ソフトバンクでは「ソフトバンクイノベンチャー」として、2011年から実施された社内起業制度があります。その第一回目に応募してきたのが現在のBBSakura Networks社長の佐々木さんでした。彼のアイデアは携帯事業者が提供している国際ローミングサービスにおいて携帯事業者同士の相互接続環境をInternet Exchangeと同じようにフラットでダイレクトに相互接続し品質を高めるというものでした。その二次審査の審査員が偶然にも私で、私が誰かもわからず彼は「これはモバイルでのBBIXのようなサービスです」と堂々と言ってのけました。「よく堂々と私の前でBBIXだ!と言い張るなぁー(笑)」と思ったのですが、そこから我々は彼の提案がうまく運ぶように資料作りを支援することになりました。案の定最終プレゼンに残りそこでなんと彼は2位と言う成績を獲得します。1位は太陽光発電に関するものでしたからICT部門としては1位でした。その会場には孫社長も参加されていましたが、その場で宮川専務(当時)が「君は今どこに所属してるのか?」問いかけ、佐々木さんは「千葉センターでNOC要員として働いています」と、すると宮川さんは「来月からBBIX出向!」といきなりその場で発言されました。佐々木くんはとても驚いたとのことですが、オフィスに帰ってみると上司から呼ばれて、「来月から出向らしい。上が決めたことだからこれはもう揺るがない。」と異例のスピードで出向が決まりました。

CloudIX研究会

Peering in Japanでの川村さんの発表以降、有志によって議論をされていたことは前述の通りですが、当社が低廉なポート料金のサービスを提供することが決まっていたので、そのコミュニティー活動や実験的な接続・研究を当社の関連する組織として作れないかと問いかけた結果設立されたのがCloudIX研究会です。このCloudIX研究会には川村さんが当時所属していたBiglobeさんや、もちろんさくらインターネットさんも参加いただきました。そしてこのCloudiX研究会に大きな転機が訪れます。私の友人で元NTT東日本相互接続部の方がNTTドコモに移られて、その彼を通じてドコモのインターネット部門の方を紹介いただきました。紹介いただいたのが現在サービスプラットフォーム部・部長の伊藤さんでした。伊藤さんにCloudIX研究会の趣旨を一通り説明し最終的には研究会に参加、そしてBBIXに接続いただくことになりました。その後の研究会の会合で私が「ドコモがテスト的にPeerしてくれるらしいけど、接続する人、挙手お願いします」と問いかけたところ手を両方上げている人がいて誰かと確認したらさくらインターネットの西村さんでした(笑)。その場で20G接続と言う意味ですね?とお伺いしたのを覚えています。それぐらいCloudIX研究会へのドコモさんの参加は大きな影響をもたらしました。

 CloudIX研究会での活動は非常に活発でありInteropでCloud間接続の実験を提供したり、事業者間でより高品質高信頼なPeeringを目指しPublic IXの中でBFDを動かしたりかなり挑戦的な試みがありました。この研究会で得られたのは技術的なTopicもありますが、一番大事なのはPeeringで相互接続しているオペレーター同士の人間関係やコミュニティーの醸成だと言うことがわかったことです。このころ社内でも当社のスローガンを決めようと検討していたのですが、ソニーWalkmanのCMをヒントに出来たのが"no peering, no internet"です。まさにCloudIX研究会での成果をスローガン一言で表すことができたと思います。命名者は当社の鶴巻さんであります。

(CloudIX研究会ロゴ)

(当時のCloudIX研究会での議論の様子)

海外進出とRPX (Roaming Peering Exchange)

前述ソフトバンクイノベンチャーで2位と言う結果を得た佐々木さんのモバイル事業者間のローミングNWの相互接続基盤を作るというプロジェクトですが、アジアのモバイル事業者の多くに接続してもらうためにはどうしても設備を香港とシンガポールに置く必要がありました。そして東京を含めた3拠点を接続し広域のPeering環境をモバイルローミングNWのために作る必要がありました。そうやって出来たのがBBIX Singapore・BBIX HongKongでありサービスとしてのRPX(Roaming Peering Exchange)です。これ以降BBIXの活動の範囲は日本にみならず海外のオペレーターとりわけアジアの事業者へのアプローチを頻繁に行うようになりました。当時アジアの中心はシンガポールと香港であり東京は市場規模こそ日本の人口が多いことから相当規模ではあったもののアジアのHUBというポジションはシンガポールと香港にありました。

 我々の戦略はアジアのモバイルオペレーターを国際ローミングNWのために誘致し、同時にインターネット側も接続していただく。そこで出来たモバイル事業者の集合体にコンテンツプレーヤーにも接続してもらうというものでした。この戦略は時間はかかりましたがほぼ狙い通りとなり現在ではアジアを中心に26のMNOに接続いただいており、多くのコンテンツ事業者に香港・シンガポールのBBIXに接続いただきました。加えて我々が海外事業者に多くアプローチした結果海外事業者の東京接続が増えたのも成果の一つです。これによりアジアのHUBの役割を香港・シンガポールだけでなく東京もその役割を果たすようになります。

(モントリオールでの佐々木のプレゼン)

BBIXの今後とBBSへの期待

このような活動を通じ現在のBBIXは、特にBBIX東京においては接続事業者210社、総接続帯域10Tbps以上、ピークトラヒックは1.43Tbpsとなり日本No.1 IXとなりました。アジア発のIXとして東京・大阪・シンガポール・香港・バンコクの接続帯域を合計しますとアジアNo.1のIX事業者でもあります。バンコクに関してはタイの事業者であるTrueIDCとの合弁により設立された会社です。このバンコクでのJV設立が周りの国を刺激し各国でIX設立の動きが活発化しております。

 今後のBBIXは接続事業者の皆様にさらなる付加価値を最新のテクノロジーを駆使し提供していくことが大切かと考えます。そこでのBBsakura Networksの役割は大変大きいと考えています。BBSについては前日の佐々木社長の記事で詳細が記されていますのでここでは割愛しますが、エンジニアが楽しい仕事を、BBIXは我々のお客さんを巻き込んで広めていきたい。そしてインターネットの発展に貢献したい。それが人類発展に少なからず役立つと信じています。「あの時BBIXとBBSが作った仕組みや基盤があるから、このサービスが出来てるんだな」とか。。。先日ソフトバンクグループ孫社長が現在はGAFAに席巻されている世の中であるが、近い将来必ずAIがゲームチェンジを起こす可能性があるとインタビューで答えられていました。我々はその時に必要な基盤や機能をJustな形で提供できるよう、必要不可欠な存在となっているよう未来を見続け頑張っていきたいと考えています。

(先日のBBIX東京のトラヒック

BBSakura Networksについて

はじめに

こんにちは。BBSakura Networks社長の佐々木です。 今日は2019年8月1日に設立したBBSakura Networks (略称:BBS)について紹介させて頂きます。 この記事はBBSakura Networkのアドベントカレンダー 7日目として書きました。

会社設立の背景

BBIXのお客様だったさくらインターネットの皆さんと色々交流する中で、自分たちで何でも作れる集団ってかっこいいな。技術者の集団だな。一緒にお仕事したいな。といろんな思いで長らく片思いをしてました。昨年の年末、会社の偉い人にやりたいな報告したら「いいんじゃない?」となりまして、本日12/7が誕生日(おめでとうございます)の上司の福智さんに、年明け初日、田中社長に告白をしてもらい、実現したのが「BBSakura Networks」です。

BBSakura Networksとは

ソフトバンクの子会社である通信事業者であるBBIXとクラウド事業者であるさくらインターネットの両社で作ったJVです。会社概要はこちらをご参照ください。 BBSではソフトウェア開発を行っており、BBSで開発したソフトウェアはさくらやBBIXで商品化され、世の中に展開されていく予定です。

企業理念

ソフトウェアの持つ可能性をもとに、全ての「モノ」が繋がる社会を支えるテクノロジーカンパニー を目指して設立しました。 コンピューターが発展し、色々なモノがネットワークに繋がる時代になってきました。ネットワークも急速に自動化が進んでおり、それらは全てソフトウェアで制御されております。 この全ての「モノ」が繋がる社会を支える為のソフトウェアを開発し、これからの世の中を支えていきたいと考えております。

コーポレートロゴ

BBSのロゴは両親会社のコーポレートカラーを元にさくらの花とツイストペアケーブルをイメージしてデザインされてます。 ネットワーク業界の様々な文化が混じり合い、溶け込み、そこから新たなものを生み出す姿をイメージしてまして、大変気に入ってます。

企業文化 - Geek's Playground

BBS設立前にどんな会社を目指すべきか、様々な議論をしてきました。 その中で出てきたキーワードがGeek's Playgroundです。 ギークなエンジニアの遊び場のような環境を目指し、エンジニアの「やりたい」ことを「できる」会社にしたいという思いで両親会社の制度の良いとこどりをしながら、日々改善を図ってます。 今実施している主な施策は以下の通りです。 - 個人裁量の拡大(開発環境/勤務形態) - フルリモート勤務・スーパーフレックス - 副業メンバー・学生アルバイトの採用 - 社外活動への積極支援

BBSでの働き方等はアドベントカレンダー1日目でみずきさんがまとめてくれてます。

テクノロジー企業で一番重要なのは「エンジニア」だと考えております。エンジニアが楽しく、毎日わくわくしながら仕事ができるような、そんな会社を目指したいと思います。

BBSakura Networksのメンバー

BBSではさくらインターネットソフトバンクから出向しているメンバーで構成されてます。私はソフトバンク出身、COOの山口さんはさくら出身で、両社から半分ずつぐらいエンジニアが出向しております。 みなさん大変個性にあふれており、会社設立前の7月に石狩DCで設立前キックオフを行いましたが、最初の自己紹介の時点で、このメンバーなら絶対に凄いことをやり遂げられるなと確信しました。 働く場所も様々で、大阪、東京、北海道、仙台にメンバーが散らばってます。日本人だけではなく、中国やインド出身のメンバーもおりますし、正社員だけでなく大学生のアルバイトや副業で業務に関わってくれているエンジニアもいます。 みんなインターネットやテクノロジーが大好きな人ばかりで、まだまだメンバーは少ないですが、すごく多様性にあふれた最高のチームです。

BBSakura Networksの将来

BBSでは世界中で使われるようなプラットフォームを作りたいと思います。 メンバーの受け売りですが、「世の中の人たちがテクノロジーを意識しなくても良い社会」をテクノロジーで実現していきたいと思います。5〜10年後、世界中で、「実はここにもBBSの技術が使われていたんだ!」というようなものを実現していきたいです。 世界で戦うには色々な困難がありますが、時には両親会社及びグループ会社の力を借りながら、世界No.1のテクノロジーカンパニーを目指して頑張っていきたいと思います。

一緒に世界を目指してくれるエンジニアを募集してます。(笑)

Portainer でらくらく!GUI Docker

こんにちは

BBSakura Networksの牧です。この記事は BBSakura Networksのアドベントカレンダー 6日目です。

RPiにUbuntu19.10をインストールして自宅サーバにしたかったのですが、RPiに乗るようないい感じのハイパバイザはまだないようなので、Dockerコンテナを PortainerGUIで管理して仮想サーバを立ててみます。

Portainerについてまとめた記事はたくさんありますが、この記事は自分がハマったところなど備忘録も兼ねてPortainerのインストールから簡単なことはじめまでをまとめています。(自分で書くと覚える)

こういう人にぴったりの記事です

この記事の out of focus

  • 他のコンテナオーケストレータとの比較
  • Windows版の手順への言及(Mac版については末尾で触れます)

Portainerについて

PortainerはDockerコンテナ上で動くOSSのDockerコンテナオーケストレータです。

PortainerはあくまでDockerコンテナをグラフィカルに表示するツールのため、Portainerが動いているコンテナをrmしたりPortainerを再設定しても 他のDockerコンテナやdocker networkなどDockerが持つ情報が削除されることはありません。

しかし、Portainerが持つ情報はリセットされる可能性があります。Portainerが持つ情報にはPortainerユーザアカウントPortainerユーザグループPortainerで設定したコンテナへのアクセス権限などがあります。

Portainerについて技術的な情報やその他詳しい情報は以下をご覧ください! - portainer.io - Portainer GitHub

機能

  • DockerをGUIで管理できる
  • Endpointを複数作成してクラスタリングできる
  • Portainerユーザによってコンテナへのアクセス権限をつけることができる
  • Portainerからコンテナのコンソールにログインできる

いいところ

  • GUIでモニタリングしやすい!
  • Dockerコマンドを打つめんどくささがなくなる!
  • docker stop しなくてもワンクリックでコンテナを潰せる!(内部では docker stop && docker rm している)

悪いところ

  • CUIのDockerが持つ機能を全て包含しているわけではない...(が大抵の基本的なことはできる)
    • DNSサーバの指定はまだGUIでできない(2019/12/5 時点)

1. Ubuntu19.10へのDockerのインストール

1.1. いつもの

# apt update && apt upgrade

1.2. 【確認事項】Ubuntu19.10のaptリポジトリについて

Dockerの2019年12月時点での最新メジャーバージョンは18です。

Docker 18は公式にはまだUbuntu19.10に対応していませんが、19.10の上でもとくに問題なく動くようです。(自宅なので気軽にOK) そのため19.10のaptリポジトリ設定を書き換えて、Docker 18をインストールします。

もし この作業をしないままDockerをインストールしてコンテナを上げる時にoci errorが出た場合は、これが原因の可能性があります。以下リンク先の記事をみてリポジトリを設定し、Docker 18をインストールしてください。 https://www.digitalocean.com/community/tutorials/how-to-install-and-use-docker-on-ubuntu-18-04

1.3. インストール

# apt install docker-ce

2. Portainerのインストール

Docker Hubからportainer/portainerをpullしてコンテナを立てます。ポートはいい感じに適宜書き換えてください。 ※Portainer側のポートは9000である必要があります。

# mkdir -p /home/portainer/data
# docker container run -d -p 9000:9000 --name portainer -h portainer --restart always --mount type=bind,src=/var/run/docker.sock,dst=/var/run/docker.sock --mount type=bind,src=/home/portainer/data,dst=/data portainer/portainer

ちゃんと上がっていることを確認してください。もし上がってなければ各関連ディレクトリの権限を確認してみてください。(👆で掘った/home/portainer/dataなど)

# docker ps
CONTAINER ID        IMAGE                 COMMAND             CREATED             STATUS              PORTS                    NAMES
xxxxxxxxxxxx        portainer/portainer   "/portainer"        2 seconds ago        Up 2 second    0.0.0.0:9000->9000/tcp   portainer

3. Portainerの初回設定

3.1. GUIへのアクセス&初回ログイン

ブラウザでPortainerが動いているDockerホストのIP:ポートを叩きます。ローカルに立てている場合は127.0.0.1:9000、RPiなどに立てている場合はそちらのIPを叩いてください。(IPをfixにしていた方がいいですね) 以下のような初回ログイン画面が出るはずなので、初回ログインを完了してください!

3.2. 管理したいDocker環境に接続

Portainerで管理したいDocker環境の形態を選択します。

今回は Portainerが動いているDocker環境のコンテナを管理したいのでLocalを選択します。

3.3. Endpointを選択

初回はすでにlocalという名前のendpointが作成されています。ここに入るとPortainerが動いているコンテナの存在を確認できます。再度endpoint選択画面に戻るには、左メニューからHomeを選択してください。

3.4. 注意点&おすすめ

  • Endpointに入った後、左メニューのContainersから、コンテナ管理(一覧、作成など)ができます。
  • コンテナを立てるときは、Command & loggingcommand/bin/bashConsoleInteractive & TTY (-i -t)を指定してください(コンテナが上がりません)
  • Portainerだけが動くendpointと、それ以外のコンテナが動くendpointを分けることで、Portainerを間違って削除しないようになどできます(それぞれの趣味に合わせて、、、)

以上で初期設定&アクセスは完了です。

Endpointの作成

Endpointを作成することで、コンテナのクラスタリングが可能になります。 今回はDocker APIを使うendpointの作成手順を記載します。

  • Endpoint URLにDockerホストのIP(ローカルのPortainerの場合、ループバックはだめ)と上で指定したポートを入力

  • Public IPにMacのIP(ループバックはだめ)を入力

  • + Add endpoint

Portainerのバージョンアップ方法

Portainerのバージョンアップは、GUIから行うことができません。(2019/12/5 時点)

  • Portainerのimagesメニューからイメージ管理画面に移動し、portainer/portainerもしくはportainer/portainer:latestをpullする(ターミナルからCUIでも可)

  • ターミナルでPortainerが動いているコンテナをdocker stopする

  • 上述の方法でターミナルでPortainerコンテナを立ち上げる

  • 正しく動くことを確認したら、旧バージョンのコンテナを消す(必要に応じてimageも消去)

Macでのインストール

Macでは以下のようにしてインストールしてください。Ubuntuよりやや手間が増えますが、何をしているかは上述の記事と適宜読み替えてください!(MacのIPは固定しといた方がよりうれしい) - Macの場合、/homeディレクトリ直下にはユーザがファイルを置けない(置けるけどめんどくさい)ので、新しくPortainer用にディレクトリを掘ります。

$ sudo mkdir -p proj/portainer/data && sudo chown -R <username>:admin proj
  • コンテナを立てる
$ sudo docker container run -d -p 9000:9000 --name portainer -h portainer --restart always --mount type=bind,src=/var/run/docker.sock,dst=/var/run/docker.sock --mount type=bind,src=/proj/portainer/data,dst=/data portainer/portainer
  • Docker APIのEndpointを作成するときはMac起動時に毎回以下コマンドを実行してください:smile: この作業をしないと、Docker for MacTCPリクエストを転送してくれません。(12345ポートに飛んできたリクエストを/var/run/docker.sockに飛ばしてくれる)
$ socat TCP-LISTEN:12345,reuseaddr,fork UNIX-CONNECT:/var/run/docker.sock
  • Endpointを作成 上記と同じようにGUIでEndpointを作成してください。

注釈

  • RPi4に公式で対応しているUbuntuのバージョンは19.10のみです(2019/12/5 現在)