journagu

nagu's journal

FlexiSpot製の昇降デスクを組み立てた

概要

天板を自分好みのサイズにしたく、どうせならと脚部分は昇降機能を持ったものを購入して若干の DIY 要素を交えて 6 万円で昇降デスクを作ったおぼえがき。

なぜ天板オーダーメイドな昇降デスクにしたか

そもそものきっかけは引っ越しの際にこれまで使用していた机のサイズが合わなくなったため。 インターネットを彷徨っていると長さ 1,800mm の天板をオーダーして DIY!!ネット通販のみで簡単に好みのデスクが作れます ♪ というエントリを見つけて「天板オーダーメイドすればすべて解決じゃん。」となったため。 昇降式にしたのは座る姿勢が悪いなか在宅ワークがメインとなり、長時間変な姿勢でいることが多くなったから。よく椅子の上であぐらかいたりしている。 昇降デスクにすれば自分で立つ座るを切り替えられるので、座る姿勢がよろしくない自分にとっては健康面で良いのでは!と思い購入した。

昇降デスクの脚と天板

自分がデスクの脚を選ぶ際に考慮したポイント。

項目 要件 理由
価格 ¥ 40,000 以内 今回の予算
耐荷重 50kg 以上 天板にデスクトップ PC とモニタを置く予定だったため。
横幅 1200mm 以下 設置予定場所のスペース的に 1200mm を超えると厳しい。
機能 昇降機能がある 機能が少ないほうがコスト的に嬉しい。
見た目 ゴツくなくスッキリしてる スマートなデスクは精神をスマートにする

昇降デスクは最近話題のFlexiSpotを覗いてみると比較的安価で見た目的にも良かったのでこの会社のプロダクトから選ぶことにした。

4 種類くらいモデルがあったがEC1(E1E)を選んだ。 なおモデル毎の比較は公式サイトに載っていたのでペタリ →  FlexiSpot 各シリーズの比較

各モデルを観ていると耐荷重、横幅は全プロダクト満たしており問題なかった。 機能面での違いは昇降範囲や昇降スピード、アラーム機能や記憶機能があるかないかなど。 昇降範囲は下限が 10cm ほど上限が 2cm ほどの差しかなかったため、EC1 と EN1 に絞った。 この 2 モデルの差はアラーム機能と記憶機能があるかないかで、アラーム機能は使う予定もうまく活用できる未来も見えず、記憶機能は都度操作すれば良いんじゃない?と思い最も安価なモデルの EC1 にした。 お値段¥ 27,700。

天板なしの実物はこんな感じ。 f:id:csnagu:20210411181640j:plain

天板はきっかけになったエントリで紹介されているマルトクショップを利用した。 木材の縦横高さの指定から角部分の処理、面部分の処理、オイル塗りなど何でもできる。 一つ難しいのが使用する木材を観たことがないと天板の色が想像できないため、実際にホームセンターなどで木材の色を確認しておくことをおすすめ。 寸法は実際に設置する場所を測って、昇降することも考慮して少し小さめで発注した。(縦 x 幅 x 厚さ:600mm x 1130mm x 25mm) 天板は送料を含めて¥ 28,050。

ここまで脚と天板を合わせて¥ 55,750。 最後に人力で天板にネジを差し込むのは骨が折れそうなため適当な電動ドライバーを購入した。

アイリスオーヤマ JCD-421-D ¥ 4,000。

これで脚+天板+電動ドライバー合わせて¥ 59,750。 タイトル詐欺せずに済んでよかった。

完成図(デスクの上が汚い) f:id:csnagu:20210411181645j:plain

雑感

ぶっちゃけ今の所強い腰痛があるわけでもないので、よほど気が乗った日じゃないとスタンディングしないっすね。。 むしろ座った状態でデスクの高さを微調整したいという意味ではしっくり来るポジションを見つけられるので良きでした。 もしかした高さ記憶機能がついてるひとつ上のモデルにしたらボタン 1 プッシュで指定した高さまで調節できるからスタンディングが捗ったかもしれない。 それと自分は天板に選んだ木材の実物を観たことがなかったため届いた瞬間はなんか違うってなったのでちゃんと実物確認しよう(大事なことなので 2 回 ry)。

MacからHyper-Vで作成したリモートの仮想マシンにSSH接続する

概要

ガチャガチャ試行錯誤する際には手元の Mac の環境を汚したくないため仮想マシンを利用したのだが、如何せんディスク容量がへっぽこなため、ゲーミング用に組んだ Windows仮想マシンを作成することにした。
仮想マシンにあまり馴染みが無く知らなかったのだけれど仮想マシンってホスト OS→ ゲスト OS は簡単にできるのに、同じネットワークにある適当なマシンから接続することが難しかった。 仮想マシンビギナーのみんなは同じ道にハマるのに(?)Google で検索してもこれ!というエントリがなかったため備忘録的にブログに落としておく。

構成としては下図のように、ホスト OS(Windows10)→ ゲスト OS(Centos8)が簡単に接続できるなら、ホスト OS を Mac→ ゲスト OS の踏み台にしてしまおうというアプローチを取る。

f:id:csnagu:20210411181941j:plain

前提・環境

  • Hyper-V でゲスト OS を作成済み
  • ホスト OS からゲスト OS へ SSH 接続できる

  • Windows10 (18363)

windows10 へ鍵認証で SSH 接続できるようにする

基本的には Windows10 で OpenSSH サーバーを動かす の手順を実施する。ポイントは 3 つ。

  • PubkeyAuthentication yes を追記
  • PasswordAuthentication no を指定
  • Match Group administrators 以下をコメントアウト

%PROGRAMDATA%\ssh\sshd_config の差分は以下のようになるはず。

# sshd_configは編集後、sshd_config.bakは編集前のファイル
$ diff /tmp/sshd_config /tmp/sshd_config.bak
34,35d33
< PubkeyAuthentication yes
<
52c50
< PasswordAuthentication no
---
> # PasswordAuthentication yes
85,86c83,84
< #Match Group administrators
< #       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys
---
> Match Group administrators
>        AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

続いて Windows10 に認証で利用する公開鍵を設定する。今回一番詰まった。 Mac にて作成した公開鍵を Windows10 へ送信する。今回は意識が低いので scp で送信する。

Windows10 にて ssh-keygen をする。生成された id_rsa.pub をコピーして authorized_keys に名称を変更し、authorized_keys ファイルの中身を Mac の公開鍵で上書きする。 ※ こんな面倒な手段をとっているのは Permission denied (publickey,keyboard-interactive). という権限周りでエラーが出たため。

ついでにデフォルトシェルを コマンドプロンプトから PowerShell に変えておく。 OpenSSH : デフォルトシェルを変更する

ゲスト OS へ鍵認証で SSH 接続できるようにする

Mac の公開鍵をゲスト OS へ転送する。 ゲスト OS に Mac の公開鍵を転送して .ssh/authorized_keys に配置する。 先ほどと同様に /etc/ssh/sshd_config

  • PubkeyAuthentication yes
  • PasswordAuthentication no

を指定する。

proxycommand を利用して踏み台を意識せずにゲスト OS へアクセスする

~/.ssh/config ファイルを編集する。

Host fumidai
 HostName 192.168.0.1
 User <windowsのユーザ名>
 IdentityFile ~/.ssh/id_rsa

Host centos8
 HostName 172.168.0.1
 User <ゲストOSのユーザ名>
 ProxyCommand ssh -W %h:%p fumidai

$ ssh centos8で接続できれば OK。

雑感

雑に設定をいじりたいときに VM はめちゃめちゃ便利なのだけど、ノート PC だとマシンスペックの融通が効かないため何かと不自由する。似たような境遇に陥った際に再現できればと思う。 最近余っているノート PC でサーバを構築したんだけど使うことが無くなりそう。。 ポートフォワーディングしたい場合は別途 Localforward などの設定が必要になるので、細かい部分は使いながら調整していくことにする。

参考

積読が消化できないからTwitterに進捗を表示させて緊張感を出したことのおぼえがき

目次

はじめに

積読が全然消化できないのでTwitterプロフィールに消化度合いを表示させると緊張感が出て捗るのでは?と思ったのでやってみた時のおぼえがき。
おまけでGitHub Actionsを利用して、プッシュをトリガーにAWS Lambdaへ自動デプロイするCI/CDチックな仕込みもやってみた。

本エントリで出てくるコードはGitHubで管理している。

github.com

GASはgist。

https://gist.github.com/csnagu/3f0e7f2a7fcf5ace1262f4c0f78e0212

動機

ある日、ふと買ったけど読んでいない本(積読)が一体どれだけあるのか気になりTodoistへ書き出してみた。

今読む読まないは別として、参考書だけで70冊ほどありこれはなんとかせねばと思いつつ、何もせずに2ヶ月経過したのでなにかしらの手を打つことにした。
3秒くらい考えて「誰にも見られないから緊張感がないのでは?」と考えついたので積読消化の進捗を公開することに。
公開するからにはよく目にする場所のほうが緊張感が高まって良さそうだと思い日頃開いているTwitterを使うことにした。

この記事を読んで「こんなもの作ってる暇あったら1冊読め」と思った人。
僕も同じこと思いました。

構成

関連サービス

  • GitHub ... コードのバージョン管理
  • AWS Lambda ... Twitterのプロフィールを更新
  • CloudWatch ... Lambdaを定期実行
  • Todoist ... 積読を管理
  • GoogleSpreadsheet ...  読み終わった書籍を管理
  • Google App Script ... Todoistで完了したタスクをGoogleSpreadsheetに記録する
  • IFTTT ... みんなの架け橋
  • Twitter ... 緊張感を届ける

盛りだくさん!

構成図

f:id:csnagu:20200419182741p:plain

TodoistとGoogleSpreadsheetの間にGoogle Apps Script(GAS)やIFTTTが抜けているんだけど図の修正が面倒なので割愛。

仕組み

積読と読了の管理・取得 - Todosit, GoogleSpreadsheetの使い分け

積読のリストはTodoistで管理し、読了したリストはGoogleSpreadsheetで管理する。このときTodositで管理する積読リストは適当なプロジェクトに分けておく(Project IDを後で使う)。
積読リストと読了リストの管理が別のアプリでややこしいが、Todoistの無料プランでは一日に完了にしたタスクを取得できないようなので割り切った。TodoistとGoogleSpreadsheetはGASを書いてIFTTTで連携させておく。

一度積読をTodoistでリスト化してしまえば、読み終わったものを完了にすることであとは自動で回ってくれる。
賢い。

Twitterプロフィールの更新 - OAuth認証とTwitterAPIとの戦い

公式リファレンスを読めば全部解決!
Twitter公式リファレンス - Authentication: https://developer.twitter.com/en/docs/basics/authentication/overview

するほどの理解力がなかったので適当にググる
"npm oauth1.0a" などのキーワードでググるとちょうど良さそうなのがあった。
ゆくゆくはAWS Lambdaに乗せて走らせようとここらへんで思い立ったので、言語はnode.jsで書くことにした。

www.npmjs.com

あとは通信だが、昔使ったaxiosを今回も使う。

Lambdaで定期実行する - AWS LambdaとCloudWatch

試行錯誤の末、ローカルでTwitterプロフィールを更新できるようになったので、続いてクラウド環境で走らせる。
日に1回実行できればいいくらい、かつ、ローカルにファイルが必要ないため今回はLmbdaを選択した。
書いたコードがそのまま動くはずなので、あまり考えずにexports.handlerの中に処理を押し込めて、zipで圧縮してLambdaへアップロードした。
これは利用しているパッケージがLambda上で利用できないため、node_modulesも含めてzipで圧縮してアップロードする必要があるため。

Lambda上で動くのを確認したら、LambdaのDesigner欄から「トリガーを追加」を選択し、CloudWatch Events/EventBridgeにて1日1実行のルールを作成する。

素晴らしい、一日一回自動で実行される様になったのだ。
(プログラムは自動で走るが本は自動で読まれたりはしない。)

GitHub Actionsで自動デプロイする - 環境変数に敗北

せっかく一部GitHubでコードを管理しているのでGitHub Actionsを使ってPushしたコードをAWS Lambdaに自動でデプロイできれば10割増しでクールに見えるだろう。
ここは非常にハマったので参考資料を適宜参照しよう。

ここのハマリポイントとしては、Lambda側の環境変数にどうやって値をセットするかという部分だ。
serverless.ymlにenvironmentとして値を設定することでLmbda側の環境変数に値をセットできるが、tokenなどの取り扱いがセンシティブな情報をymlファイルに書いてGitHubにアップロードするわけにはいかない。
GitHubのSecretsから値を取得しようとも試みたが、Secretsの値を扱えるのはどうやらGitHub Actionsのジョブを定義しているymlファイルからのみのようで実現できなかった。うまいやり方が無いものか。。。
(そもそも秘密情報を環境変数で扱うのは間違っているような気がしていて、別の手がありそう。)

感想

async, await周りの理解が拙くて、1 / 70 のような表記にしたかったのに NaN / undefined となってしまった。
また、Twitterで触れたOAuthやTodoistで触れたBearerToken周りの理解が足りていなくて問題の切り分けがやりづらく感じたので上辺だけでも理解したいなと。
実装面やデプロイ面に関してはベストプラクティスのようなものがわからないまま突き進んでしまったので、このブログエントリを読んだ詳しい人教えて下さい。

何はともあれGitHub ActionsとServerlessFrameworkを使ってAWS Lambdaへの自動デプロイができたので、今後似たようなことをやるときには割とすんなりできるようになっていると思う。

積読消化進捗がTwitterで確認できるようになったので(しかも自動更新!)、これで少しは捗るといいな。

ゼロから実践するAmazon Web Services。手を動かしながらインフラの基礎を習得のおぼえがき

f:id:csnagu:20191123173559p:plain

はじめに

山浦 清透(@ kiyotoyamaura)さんがUdemyで公開している「AWS:ゼロから実践するAmazon Web Services。手を動かしながらインフラの基礎を習得」を観てみたおぼえがき。
AWSのLambdaやS3は使ったことがあったが、AWSのサービスを組み合わせてインフラを作ったことがなかったため、勉強がてらやってみた。

Udemyのコース: https://www.udemy.com/share/101YbyCUYed1xXR3Q=/

コースの内容

コースは基礎編と発展編の2セクションに大別できる。

基礎編

IAM / CloudWatch / CloudTrail / VPC / EC2 / Elastic IP / Route53 / RDS / WordPress についての説明とハンズオンがある。
主にやることは以下の通り。

GCPやAzureなど使ったことがなくAWSほんとになんもわからんという人向けに感じた。キイタコトアル人は2倍速で再生すると丁度いい。 インフラを作ろうということで、コースの途中でTCP/IPやHTTPとはみたいな話があるが、あまり深く掘り下げないので別に参照するものをおいていたほうが良さそう。下記参考書籍を読んでおけば特に詰まることなく進められた。

参考書籍:
Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)
マスタリングTCP/IP―入門編―(第6版)

発展編

S3 / CloudFront / ELB / RDS / AMI / CloudWatch / IAM についての説明とハンズオンがある。 主にやることは以下の通り。

  • WPの画像保存先をS3に変更する
  • S3の画像をCloudFrontでキャッシュする
  • 独自ドメインで画像を取得できるように代替ドメインを設定する
  • EC2インスタンスを増やしてELBでWebサーバを冗長化する
  • RDSを冗長化する
  • CloudWatchでメトリクスの監視設定をする。アラートを飛ばす
  • IAMでポリシーやユーザグループ、ロールなどを作成してアクセス管理を学ぶ

インフラ設計における重要な観点

  • 可用性 ... サービスを継続的に利用できること
  • 性能・拡張性 ... 性能は十分であること、将来的にシステムを拡張できること
  • 運用保守性 ... 運用保守がしやすいこと
  • セキュリティ ... 情報が守れらていること
  • 移行性 ... 他のシステムに移行しやすいこと

メディアの保存先をWebサーバーから分離するメリット

  • Webサーバのストレージをメディアで圧迫しない
  • HTMLへのアクセスと、メディアへのアクセスを分けて負荷分散する
  • Webサーバの台数を増やしやすくなる
  • コンテンツ配信サービス(CloudFront)から配信することで、高速化できる

IAMについて

  • ポリシー ... EC2とS3といったリソース対するアクセス権限の定義
  • ユーザー ... 君や私。ポリシーが割り当てられる
  • グループ ... 複数ユーザへのポリシー割り当てをまとめて行える
  • ロール ... EC2やLambda等のAWSリソースに対して設定するアクセス権限

ポリシーは基本的にユーザやグループへ割り当てるために利用する。一方で、ロールはAWSのリソース(EC2、Lambda等)に対してアクセス権限を付与する際に利用する。アクセス権限が必要な操作を行うときに、一時的にアクセスキーとシークレットキーを発行して利用する。バックではAWSのKMS(Key Management Service)を利用しているらしい。 ポリシーとロールの違いがチョット怪しい。(~_~)

WebサーバとDBサーバを分けたら何が嬉しいのかと言うのは [Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ) に詳細に書いていた気がする。

感想

AWSとかいうの正直サービスが多すぎて何から手を付けて良いのかわからんという状態だったが、目的を持って(今回の場合はWordPressを立ててみよう)体系的に学べるのは非常に良い。こういうのを積み重ねていくとユースケースが自然と刷り込まれていって、課題に対する反射神経が上がるのかなと思った。
Route53でドメイン利用できるようにしたり、CloudFrontを利用したら本当に早くなってるじゃんって確認するところは楽しかった。WebサーバとDBサーバを分けるところのように、何故するのかが説明されているのは良き。

また、初Udemyということで書籍との感覚の違いについてもメモしておく。LTとかスライド的なものを見るのが好きな人はもちろん、初めてで何もわからんからハンズオン的に手を動かして学びたい場合は、書籍よりもUdemyやpluralsighのような動画コンテンツで学ぶほうが圧倒的に良いと思った。目の前で操作がされており、操作を見逃したとしても5秒前とかに戻って確認することが容易なためとにかくとっつきやすい。
一方で既に知っている内容をスキップするときにスキップしすぎたりということが発生するので、ここらへんは書籍のほうがペースをつかみやすいなと思った。

入門 監視のおぼえがき

f:id:csnagu:20191007224613j:plain
入門 監視

はじめに

Mike Julian 著、松浦 隼人 訳な『入門 監視 ――モダンなモニタリングのためのデザインパターン』を読んだおぼえがき。

そもそも『入門 監視』を購入するに至った経緯についてだが、2019年の下期からログのプラットフォームを運用するチームに配属となった。この時点では「ログや監視まるでわからん」といった感想しか持っていなかったため、流石に「これはいかん」となり、少し前に自分のTLで話題になっていた『入門 監視』を読み始めた。

入門 監視を読んでみて

『入門 監視』は、監視ツールに依存しない監視の基本だったり、なぜ監視するのかといった、基本的な部分を丁寧に解説してくれている。
監視のアンチパターンからデザインパターン、ビジネスKPI・フロントエンド・アプリ・サーバ・ネットワークなどコンテンツがたくさんあるが、各章では「何を、なんのために、どのように監視するのか」がまとめられていて非常に良い内容だと思う。

そのため、自分のような「どんな背景があってXXXを監視しているのか」「そもそもなぜ監視するのか」といった基本的な部分を補うのに最適であったように思う。

また、OSSの監視ツールがある中で、商用のSaaSを利用する理由やメリットなどは納得感があったし、業界や企業側の世界観がいまいちつかめていなかった自分としては学びが多かったように思う。ロギングや監視といった主軸のコンテンツからは若干逸れるが、OSSを採用するか商用SaaSを採用するかは、安定稼働までのコストや機会損失、セキュリティ面などを総合的に判断しなければいけなく、必ずしもOSSバンザイな姿勢ではいけないことを学んだ。

その他にも、運用に関する手順書を作成するのは作業途中に人間の判断が必要な場合だけにして、ログやメトリクスを監視することで積極的に自動化してしまおうといった話題は面白かった。

最後の章には総まとめの例題がある。フィクションのコンサルタントを例に、本書を通して学ぶ「何を、なんのために、どのように監視するのか」を確認させてくれる内容となっていた。全体を思い返すのに非常にいい構成だったと思う。

もう少し実務を積んでから読み返すことで新たな気付きがありそうな気がとてもしている。定期的に読み直していきたい。

www.oreilly.co.jp