■
手のひらサイズの高性能8コアRyzenベアボーンキットをCrucialメモリ& SSDでハイコスパ仕様に仕上げてみた ~サイズは極小、実用性は十分。メモリとSSDを賢く選んで仕事にも余暇にも活躍する1台に!!- PC Watch[Sponsored]
https://pc.watch.impress.co.jp/docs/topic/special/1326964.html
ASRock 4X4 BOX-4800U/JP 4X4 BOX AMD Ryzen™ 7 4800U プロセッサー搭載小型ベアボーン - 製品詳細 | パソコンSHOPアーク(ark)
https://www.ark-pc.co.jp/i/31400989/
4X4 BOX-4800U/JP 4X4 BOX AMD Ryzen™ 7 4800U: 79,970
Crucial CT2K8G4SFS832A。PC4-25600 : 12,177
Crucial P5 CT1000P5SSD8JP。PCI Express 3.0 x4 : 17,152
Crucial MX500 CT1000MX500SSD1/JP : 11,133
合計で120,432円になる。これならミニデスクトップPC(?)買った方が良い気がする。
ファンレスや設置スペースを気にしないのならデスクトップでいい。
結局庫内のエアフローが生まれにくく、排熱処理で不安抱えるだけ。
自作NAS用途にしても24時間365日動かすには排熱の点で不安だし、サーバとして使うにしても用途がも1つ見つからない。それなら最低構成でAWSやGCP借りてやった方が良い気がする。
たまーにミニベアボーンを見るのだが、やっぱりその人の用途次第。
よくあるのが飲食店のPOS端末として、モニターの後ろに張り付けて使いたいとか。
駅構内で通路に沿うように細ーく長ーく並ぶ売店などで本当に店舗スペースが限られてる場合などには活躍の場があると思う。
それ以外はその人の趣味。
小さく安くっていうならRaspberryPi4+miniSD+外付けHDD+USB-HUB+キーボード/マウスで構築すれば3万も出さずに済む。
もっと小さくっていうならRaspberryPi Zeroがある。zero+miniSD256GでWi-Fiでデータ飛ばして・・・っていう使い方すれば2万でもお釣りがくる。
RaspberryPiが出るまではミニベアボーンは垂涎の的だったけど。
あとはRaspberryPiだと処理力の面で不安がある場合は使うかなあ。
ただメリットは小さくなったよね。
Cloud9 でaws cliするのにこんなに悩まされるとは思ってなかった
assume roleが絡んでるので実際は違うと思うが、だいたいのところは分かった。
というかcloud9立てる時点で 待つこと40分近く?
こんなエラーがでやがった。うそやろ?
っていろいろテキトーに見て回ってたら設定するVPCが💩だったようでw
道なりに進めと書いててもちゃんと確認しようぜ!
やったことはここに書いてある通りのことしかやってない
[ Cloud9からIAM Roleの権限でAWS CLIを実行する | DevelopersIO ]
( https://dev.classmethod.jp/articles/execute-aws-cli-with-iam-role-on-cloud9/ )
1)cloud9のPreference()⇒AWS Settings⇒Credentials/AWS Managed Temporary credentialsのトグルボタンをOFF(無効)にする。
2)AdministratorAccessロールを割り当てたIAMロールを、cloud9のEC2に割り当てる
ここで記事と画面が違ってすっごく迷った(AWSはいつもユーザー虫だからな)
3)EC2インスタンスを選択し、
アクション⇒ セキュリティ⇒ IAMロールを変更
ここでロール変更(設定)ができる。
これで「Cloud9が一時的なクレデンシャルキーを自動的に取得」になる。
4)aws configure listでステータスを確認。
5)環境変数 AWS_DEFAULT_REGIONにリージョン名を設定
export AWS_DEFAULT_REGION=ap-northeast-1
6)コンフィグリストに反映されていることを確認
7)./awsに、configファイルを作成
[default]
region = ap-northeast-1
を書いて保存(echoでリダイレクト出力でもよい)
8)IAM Roleの権限でAWS CLIの実行
IAMユーザーを新規作成
aws iam create-user --user-name sample-user
{
"User": {
"Path": "/",
"UserName": "sample-user",
"UserId": "USERIDxxxxxxxx",
"Arn": "arn:aws:iam::9999999:user/sample-user",
"CreateDate": "2021-99-99T17:42:40+00:00"
}
}
これが実行できたら aws cliが利用できることを確認できたことになる。
ちなみにAMTCをONにすると
An error occurred (InvalidClientTokenId) when calling the CreateUser operation: The security token included in the request is invalid
(CreateUser操作の呼び出し時にエラーが発生しました(InvalidClientTokenId):リクエストに含まれているセキュリティトークンが無効です)
と表示されてエラーになる。
AMTC設定はデフォルトONという話だが、なんでONなのかがわからない。
こんなのどこで見つけりゃいいんだよw
実施したのは個人の環境なので何も気にせずやれたので良かったが、あまり下手打ちできないなあとも思った。
階層を指定して特定ファイルを数える
[ findコマンドで検索する階層を指定(maxdepth) | ubuntu | マイノリティでいこう ]
( https://blog.be-dama.com/2015/01/20/find%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%81%A7%E6%A4%9C%E7%B4%A2%E3%81%99%E3%82%8B%E9%9A%8E%E5%B1%A4%E3%82%92%E6%8C%87%E5%AE%9Amaxdepth/ )
vagrant で動かしているものを見るのに時間かかり過ぎて困る
vagrant global-status --all | Select-String running
そもそもvagrant status で出せればいいのに、いちいち全件だして、powershellだとSelect-Stringでフィルタリングしないと無理っておかしくないか?w
もっと楽で、早く出せる方法ないんだろうか
vagrantでLaravelウェブアプリを作る(2-2)
つづき。
というか本来なら
1.実行環境(PHP、Python、node/nvm)の準備
2.ウェブサーバ(nginx)の準備
3.ソース管理(Git)の準備
を行うべきなのだが、前々準備なことをやっている。
本来ならこういう構成をしたいのだが、プロキシやLB、WAFまで手が回らないのでとりあえずnode1/2を置いて実行環境やweb、DBサーバ置いて、LaravelやVueのデフォを動かしたらホスト(☁印)からアクセスできるよね。
ってところが確認できればOK。というマイルストーンで考えている。
しかし。
ここでふと思ったのが起動や処理をしたとき、本当に正しく起動し、動き、停止したかという動きをチェックする必要がある。
Vagrantでプロビジョニング(設備準備)を行う場合 config.vm.provisionでインストールや設定をシェル(インライン又は外部ファイル)、Puppet、Chef、Ansible、Dockerが使え、runオプションで always、never、無し が設定できて、毎回実行するか否かを明示的に指示できる。
更にnodeごとにプロビジョニング内容を変えることも出来る。
今回の場合ならnode1が動いていればいいわけだが、node2の状態を見たい。またGuestOSの起動、シャットダウンを繰り返したりするわけなので、都度都度コマンドを打って状態を確認するのは本当に面倒臭い。Zabbixなど監視ツールは無事起動した後の運用時に使うもので大がかりすぎる。
そこでここでお手製のシェルを作って起動させたら各状態を確認しにいき、レポートファイルを見たら状態が一見できるようにしたい。
作り始めたは良いがここでポカミス。わりと四苦八苦してしまった。
(ちょっと調べものを鵜呑みにし過ぎたかも)
目的は起動チェッカー、ステータスレポート作成。そして作成したレポートは共有のところに格納。格納先は年、月、nodeの階層でディレクトリを作成し、年月日時分秒のサフィックスを付けたレポートファイルを格納する。
というところまでが出来た。
当初目標は
*起動の都度、毎回実行するプロビジョニング
・GuestOSのアップデート
・ホスト側、対抗node側の疎通確認
・各ミドル起動確認
nginx、posgtresql、mongoDB
apache-http、ElasticSearch、(MySQL、SQLite)
・Git状態確認
・ログ状態確認
・ヘルスチェック
・ログ状態確認
・ログ未送致分の確認
・通知(ノーティフィケーション)状態確認
・通知未送致分の確認
・各ミドルのライフタイム切れ事前通知
これらを一括で行いレポートに出力させたい。
とはいっても俺のことなので3つ目くらいまでで息切れしそうだけど。
次は頭から3行目あたりのことをshellに実装していく。
(参考)
Basic Usage - Provisioning | Vagrant by HashiCorp
( https://www.vagrantup.com/docs/provisioning/basic_usage )
shopt -u histappend って?
コマンド履歴を複数の端末で「共有化」する方法【Bash・history】 | LFI
( https://linuxfan.info/history_share )
shoptってメジャーなんだろうけど個人的に使ったことがなかった。
もともとHISTTIMEFORMATのことで調べてたらshoptにぶつかって調べ始めたもの。
shoptコマンドで設定できるbashの便利設定まとめ | 俺的備忘録 〜なんかいろいろ〜
( https://orebibou.com/ja/home/201704/20170411_001/ )
こちらも細かに書かれていたのだが、どちらかと言えば個別のシェルオプションの説明はこっちの方がわかり易かった
【 shopt 】コマンド(応用編その1)――コマンドライン履歴の扱い方を変更する:Linux基本コマンドTips(362) - @IT
( https://www.atmarkit.co.jp/ait/articles/1912/12/news034.html )
便利機能ではあるけど本当に必要?と思うものも多々。
あとshoptを永続化をbash_profileとかで保存するのかもしれないが、環境によって設定が様々だと変なトラブルが生じないか心配になる。
どの環境でも同じ挙動であることがオペレーションミスを生じさせないためにもshoptは極力使わない方が良いと感じた。
vagrantでLaravelウェブアプリを作る(2)
今の想定はこれで考えている
node1/2はLB構成を考えたもので、中身は1も2もほぼ同じ。
ただこれオンプレぽい構成なのでどうにかKubernetesやDockerの形にしたい。
構成管理はAnsibleを使いたい。ソースやビルド、デプロイはJenkinsに任すとかできないかなあと夢。
アプリのソースを除いた他の部分はすべて自動で設置させたい。
妄想癖はこのくらいにしておいて、前回の続き。
やらないといけないのは
1.実行環境(PHP、Python、node/nvm)の準備
2.ウェブサーバ(nginx)の準備
3.ソース管理(Git)の準備
本当ならVagrantfileのプロビジョニングに書いておきたいのだが、ここまでに至るところで色々問題があって、じゃあ1つ1つ皮剥いでクリアしていくしかないねということで1から手動で準備することにした。
ハローワールドやデフォ画面が表示できたらOK とした。
ーー
vagrant upして起動。問題なし。
次にvagrant sshで接続したが、あえてnode選択せずにやった
PS G:\SANDBOX\500dev\PHP\sandLaravel> vagrant ssh
This command requires a specific VM name to target in a multi-VM environment
(このコマンドはマルチVM環境でターゲットにする特定のVM名が必要です)
まあ当然な結果。
PS G:\SANDBOX\500dev\PHP\sandLaravel> vagrant ssh node1
vagrant@ubuntu2010:~$
これでnode1にアクセスできた。
だがしかし。これではnode1とnode2どっちにアクセスしているか判別つかない。