reveal.js とreveal-ckでプレゼン資料作成

reveal.js

最近、パワーポイントからの脱却を目指してます。

パワーポイントにも良いところあるけど、個人的にはあまり凝った資料作成しないし、diff しやすいテキストベースのほうが良いかなと。

概要

html or markdown などでプレゼン用資料が作成できる

reveal.js

色々あるけど、一番簡単なのはhtml 内のdiv class="slides" 内のsectionにmarkdown書く。
sectionタグに1pageごと書くのがめんどくさいので---などを区切りにする方法。

  • --- がページの区切り
  • >>>が補足用などで縦方向のページ区切り (data-separotor-verticalで指定)
<section data-markdown 
       data-separator="^\n---$" 
       data-separator-vertical="^\n>>>$">
    <script type="text/template">
Page 1

---

Page 2-a

>>>

Page 2-b

>>>

Page 2-c

---

Page 3
  </script>
</section>

markdown を別ファイルから読み込む方法もあるけど、その場合はnode.js でlocalにwebserverを起動する必要がある。

reveal-ck

ruby製のブツ。一つのmarkdownファイルを元にreveal.js 用の静的を生成してくれる。
reveal-ck start するとlocalhost に10000番のweb serverが起動して、slides.md を編集すると自動的にreload＆静的ファイルを再生性してくれるので、資料作成するときの確認が簡単。

$ gem install reveal-ck
$ echo '# hoge' > slides.md
$ reveal-ck generate
$ reveal-ck start

Github/Gitlab Pages、CIあたりで連携しておけば、slides.md をcommit & push したら公開用のhtmlが自動的に更新される、みたいなこともできるらしい、ええなー。

apache 2.4.7 からProxyPassでunix domain socketを指定できるようになってた

apache

nginx + uwsgi(socket) で動いているブツを、apacheが稼働中のサーバに移そうとしたときに、
socketをtcp port に書き換えないといけないの面倒だなーと思ってたけど、2.4.7 からsocketに対応してた。

Unix Domain Socket (UDS) support added in 2.4.7

でもRHEL/CentOS 7の標準のhttpdは2.4.6なので使えない 😇

apache 2.2 LocationMatch 内ではProxyPassではなくProxyPassMatch (ただし、ProxyPassReverseの制限付き)

apache

2.4は不明。2.2ではProxyPassではダメだった。

Location 内でProxyPassしているURLを増やしたくて、
そのままLocationMatchで正規表現で書いてもProxyしてるところがbackendに渡らなくて困った。

セクションの中で使われた場合は、 最初の引数は省略され、正規表現は から取得されます。

ProxyPassMatch の場合は渡す引数を正規表現でとってこないといけないので
URL /foo/ 

<Location /foo/>
   ProxyPass http://backend/foo/
</Location>

URL /fooもしくは/bar

<LocationMatch ^/(?:foo|bar)/(.*)>
   ProxyPassMatch http://backend/foo/$1
</Location>

最初のカッコはfooとbarをグループしたいだけで変数はキャプチャしたくないので?: つけている。


これで動作はする。ただしProxyPassReverse の扱いがやっかい。
Locationで使っていた

ProxyPassReverse http://example.com/foo

をそのままLocationMacthで利用すると、backendでredirectが発生したときに正規表現の文字列のまま返ってきてしまう。

$ curl -I http://example.com/foo/hoge
(抜粋)
Location: http://example.com^/(?:foo|bar)/(.*)/hoge/

これはProxyPassReverseのドキュメントにも書いている

セクション内でも起きますが、 おそらく意図どおりに動きません。
と言うのも、ProxyPassReverse が正規表現をそのまま文字列でパスとして解釈しようとするからです。
もしこのような状況で必要なら、セクションの外で ProxyPassReverse を指定するか、あるいは別の セクション内で指定してください。

ここまでくるとアプリケーションやどのURLでアクセスがきたときにどうしたいかなどによるけど
一つのProxyPassReverse ではたぶん綺麗に解決できないので、
ProxyPassReverseが必要な状況なら素直にLocation を個別に書いた方が良いかな。

Google Cloud Certified - Professional Cloud Architect に合格しました

gcp

cloud.google.com

シリーズIDは2000後半でした。今年頭に合格した人が1000前半だったことを考えると順調に増えていってますねー。

AWS のソリューションアーキテクトアソシエイトよりは難しかったと思います。
(プロフェッショナルはまだ受けたことないのでわからない)


ちなみに

英語版だとAssociate Cloud Engineer というのがベータで始まったので、
AWS ソリューションアーキテクトアソシエイト相当はこの資格になるのかな？

rancher v1.0 memo

rancher

version 1.0 時代のmemo 見つかったので引っ張り出してきた。
最新は1.4 なので色々変わってると思うけど。

http://rancher.com/rancher-os/

  • iso イメージからboot
  • 自動的にコンソールログイン、DHCPでIP取得
  • 作業はrancherユーザ。sudo でroot権限使う。
  • cloud-config.yaml を書いてros コマンドでinstall

- sshの公開鍵もこれに書く
- vCenterのコンソールからコピペは難しいので、作業用のためにrancherユーザにパスワード設定して、sshで入って作業するのもあり？

sudo ros install -c cloud-config.yml -d /dev/sda
sudo ros service list
sudo ros service enable open-vm-tools
sudo ros service up open-vm-tools
sudo ros service enable rancher-server
sudo ros service up rancher-server

cloud-config.yaml sample

#cloud-config
hostname: rancheros1-1
ssh_authorized_keys:
  - ssh-rsa "sshの公開鍵" user@host
rancher:
network:
  interfaces:
    eth0:
    address: x.x.x.x/y
    gateway: x.x.x.1
    mtu: 1500
    dhcp: false
  dns:
    nameservers:
      - y.y.y.1
      - y.y.y.2

# ホスト network 設定変更

sudo ros config set rancher.network.interfaces.eth1.address 1.1.1.1/24
sudo system-docker restart network

# nfs mount

amazon EFSじゃなくて自前のnfsを使う場合

```
NFS Server: NFS server ip address or hostname.
Export Base Directory: Exported shared directory on the NFS server.
NFS Version: The NFS version to use, current used version is 4.
Mount Option: Comma delimited list of default mount options, for example: ‘proto=udp’. Do not specify nfsvers option, it will be ignored
```

## volumeの設定

  • インフラストラクチャ - ストレージ - ボリュームを追加
  • 名前を適当に入力: nfs exportディレクトリのサブディレクトリとして作成される
  • "test" とすると nfs-server:/path/to/export/test でmountされる
  • 作成した段階ではinactive状態
  • インフラストラクチャ - コンテナ
  • ボリュームタブ 作成したtestをコンテナの/path/to/mount でmountしたい場合
  • test:/path/to/mount
  • nfsボリューム作ってない場合に↑をやると、localにtest というvolumeできてしまうので注意


# コンテナnetwork

  • コンテナ作成時のネットワークはデフォルトで"管理" 10.42.0.1/16 ? (英語だとmanaged)
  • 基本的には管理で良い
  • ホスト間でipsec貼られているのでホストに依存せずコンテナ間で疎通可能
  • ネットワーク: ホスト にするとコンテナホストとinterface状態になる
  • eth0、eth1、docker0 など全て引き継ぐ


## network 分離

Network Policy Manager カタログをデプロイすれば、サービス内、スタック内では許可、その他は拒否、というような設定が可能。

ちなみにスタックから起動せず、インフラストラクチャ - コンテナから起動したコンテナはどのスタックにも紐づかないので
"その他: 拒否" にしている場合はどのコンテナ間とも疎通は不可となる。