デスクトップPCを自作購入した

なぜデスクトップなのか

ノートパソコンを少し前に買った が、金額に対して得られる性能に不満があった。正直コスパが悪いと思う。
昨今の情勢もあり、カフェ作業する機会もほぼなくなったし、Appleの気まぐれ(バグ)で iOS14 のテザリングが壊滅したので踏ん切りがついた。

購入選定

Intel NUC -> BTO ショップ PC -> 自作PC の順に検討が進んで、自作PCに落ち着いた。
NUC はサイズの割に高性能なのはよかったが、性能の割に高価なのとグラフィックボードはほぼ積めず、その場合は NUC なのに大きいのでやめた。

BTO ショップはハイスペックなPCを探すとほぼゲーミングマシンしかなく、高い性能のグラフィックボード(5-6万)はあってもメモリは16GBという歪なバランスの PC しか組めないので断念した。

自作するにあたり、要件は以下とした

  • マザーボード: 今後パーツ入れ替えできるように拡張性重視 -> X570 系
  • CPU: コスパと省電力性重視 -> Ryzen5 3600
  • メモリ: 32GB 以上 -> 32GB * 2
  • GPU: ビデオ会議に普段から耐えられる性能。CPU とは別。稀にゲームや動画編集できる -> GeForce GTX 1650 Super
  • ディスク: 早ければ早いほどよい。512GB以上 -> NVMe対応SSD 1TB

自作 PC は10年ぶりだったので2週間くらいハードウェア事情のキャッチアップをして、PCワンズで揃えた。

www.1-s.jp

後から秋葉原の有名ショップをいくつか見てみたが、ワンズの単価はショップの店頭価格よりも少し安いことが多かったので、ネット通販で買ってよかったかなという印象。

以下、パーツ一覧。

●Ryzen 5 3600 With Wraith Stealth cooler (6C12T/3.6GHz(4.2)/65W/Total Cache 35MB) 0730143309936
◇AMD
@24,700×1=24,700 (税込)

●TUF GAMING X570-PLUS 0192876388457
◇ASUS
@18,480×1=18,480 (税込)

●MasterBox CM694 TG (MCB-CM694-KG5N-S00) 4719512087299
◇Cooler Master
@15,800×1=15,800 (税込)

●NeoECO Gold NE550G 0761345116244
◇Antec
@9,080×1=9,080 (税込)

●AD4U3200732G22-D 4582353591719
◇A-DATA
@25,690×1=25,690 (税込)

●PH-GTX1650S-O4G 0192876557655
◇ASUS
@20,980×1=20,980 (税込)

●Windows 10 Pro 64bit 日本語 DSP版
◇Microsoft
@21,290×1=21,290 (税込)

●WDS100T3X0C 0718037865393
◇Western Digital
@16,280×1=16,280 (税込)

この構成だとフロントファンの給電ケーブルだけは追加購入必要だった。
参考: 価格.com - 『フロントファン2つが回りません』 COOLER MASTER MasterBox CM694 TG MCB-CM694-KG5N-S00 のクチコミ掲示板

組み立て

各パーツの説明書とネットの自作ガイドを参考にやった。
大体2,3時間くらいでゴミの片づけ含め完了。
今からもう一回やるなら1時間くらいでできると思う。

ASCII.jp:ジサトラ見習いが初自作に挑戦! 初心者でもわかる、Ryzenで組むPC自作の心得 (1/6)

合わせてそろえたもの

43 インチディスプレイ

2017/3 に当時セールで6万円ほどで購入したものを繋げて使っている。
少し前までは仕事用に 27 インチディスプレイを使っていたが、大きいは正義なのでこっちに変えた。

USB 切替器

仕事でもプライベートでもよい外部デバイスを使いまわしたいので切替器を買うことにした。
USB3.0 以降で4ポートある切替器が欲しかったのでこれになった。
キーボード、マウス、Webカメラ、ヘッドセットで4個埋まる。
今のところは給電ケーブルなしでどうにかなっている。
USB3 にこだわったのがよかったのかもしれない。

LAN スイッチングハブ

インターネット有線接続は切替ではなく同時に接続するのも同じだし、端末が増えたとき(ラズパイなど) にネットワーク上繋がっているほうが何かと都合がよいのでハブにした。
小ささと 1000Mbps のバランス感。

ベンチマーク

比較しても仕方がないが、以前使っていたノート PC とベンチマーク比較を取った。

Cinebench 997 -> 8732

f:id:khei-fuji:20201227093712p:plain
Cinebench

最も差がついたのが CPU。

CrystalDiskMark 1774 -> 3142(Read)

f:id:khei-fuji:20201227093732p:plain
CrystalDiskMark

SSDは善戦してる。ノートPCでも M.2 NVMe 対応の SSD だったので、この数値の差はモバイル用かどうかの差だと思う。

3DMark TimeSpy 2317 -> 4931

f:id:khei-fuji:20201227093818p:plain
3DMark - TimeSpy

はじめに PC 組み上げたときはどうしても 3DMark のスコアが出ず、組み直したところ改善した。(上図は改善後)
2つあるグラフィックボードの電源コネクタを差し替えてみたところ解決したが、この原因はよくわかってない。

3DMark Firestrike 4184 -> 11069

f:id:khei-fuji:20201227093758p:plain
3DMark - Firestrike

DirectX 11 系もということで一応取っている

FFXV 中断 -> 5015

f:id:khei-fuji:20201227093845p:plain
FFXV

ノートPCでは途中でフリーズした。

おわりに

環境も整ったのでいろんなことをやっていきたい

GitHub Actions と Azure Pipeline を両方使っていて思うことを書く

この記事は Azure DevOps Advent Calendar, GitHub Actions Advent Calendar 11日目の記事で、表題のとおり両方を実用していて思うところを書く。

はじめに断っておくと、この記事ではマルバツの比較表は出てこない。
特徴を理解して使い分けが必要というのが結論。

はじめに

サービスができた歴史上、GitHub Actions のほうが後発なので、足りないところを感じる場面が多々ある。
たとえば Yaml の書き方で不便さを感じたり、欲しい job が用意されてなかったり、細かい制御ができなかったりという具合だ。

Yaml の書き方

前提として git-flow に近い形で CI/CD を組むことが多いため、それに沿った書き方をしている。
develop に対して開発環境、 master に対して本番環境があるイメージ。

このときのリリースパイプラインは、トリガーやリソースは環境ごとに異なるが、処理の流れは同じパイプラインを組む、としている。
これを Azure Pipeline で組むと、 Template を作ってそこに環境毎の変数を渡す、という形が実装しやすい。

- stage: xxxx
  variables:
  - group: 'dev-env-variable-group' # ここが prod だと変わる
  jobs:
  - template: deployment-template.yml
    parameters:
      azureConnectionName: '$(AzureConnectionName)'
      resourceGroupName: '$(ResourceGroupName)'
      environment: 'DEV' # ここが prod だと変わる

これと同じことを GitHub Actions でやろうとすると、やりづらい。
そもそも GitHub Actions には Template がない
そのため、ブランチによって処理を変えるなどの対応をするか、Yaml を複製することになる。

ここに対するいいアイデアがあったら知りたい。

GitHub Actions で使いたい Job がない

ないのはどうしようもない。
なかったら作ればいいじゃない、ということで GitHub Actions Advent Calendar を見ると結構多くの人が作っているのがわかる。

GitHub Actions では 6000 以上の Job が Marketplace に公開されているとのこと。
私も1つ作った。
kheiakiyama.hateblo.jp

個人的にはイチから OSS を作る機会は初めてだったので、いい経験になっている。

GitHub Actions で細かい制御ができない

Azure Pipeline ユーザにはおなじみの Approvals and check 機能GitHub Actions にはない。
と書くつもりが、 GitHub Universe で今月末にベータ版が公開されるという発表があった。

Environment Protect rulesでは、例えばデプロイ前に人間(required reviewers)の承認を求めるようにしたり、時間を置いたりできる(今月末にベータとして利用可能予定)
GitHub Universe 2020の基調講演で発表された新機能を紹介、GitHub ActionsのアップデートやDependency reviewなど - クラウド Watch

GitHub Actions の agent は Azure Pipeline の fork ということなので、今後も Azure Pipeline にある機能は適宜取り込まれると期待してよさそう。

The GitHub-hosted runner application is a fork of the Azure Pipelines Agent
Specifications for GitHub-hosted runners - GitHub Docs

ところで GitHub Actions のほうが軽量で実行が速い気がするのは fork だからなのだろうか。

導入するまでの敷居

どのクラスタに対して存在するツールか、という問題だと思っている。
自分がたまたま Azure を利用する立ち位置なので敷居は高くないが、たとえば AWS ユーザに Azure Pipeline 勧めるのは現実的ではない。
とはいえ AWS ユーザにも GitHub(Microsoft 傘下!) はかなり使われているため、GitHub Actions に抵抗はそう感じないはずだ。

また、Azure Pipeline ひいては Azure DevOps を使うとなると、エンタープライズ向けのもろもろの機能がついてきてしまうため、そこに目がいってしまい、まずは CI/CD だけ手軽に導入して試す、となりづらい印象がある。
(それもあってか Azure ではいくつかの機能は内部的に Azure Pipeline を作成する、という挙動がある。個人的にはあまり好きではない)

この点、GitHub Actions は GitHub ユーザにスムーズに利用してもらえる位置づけである。
実際のところ、サービス公開以降 Travis CI や Circle CI ユーザが移行しているのを SNS 上で見かけることは多い。

おわりに

ということで、どちらも甲乙つけがたいので今後も両方使い続けていきたい。

GitHub Actions / install-azcopy-action v1.0.2 リリース

github.com

azcopy をインストールする GitHub Action "install-azcopy-action" v1.0.2 をリリースした。
内容はセキュリティアップデートをいくつかと、GitHub Actions の Deprecated になった処理の対応。
Deprecated のニュースは以下。

GitHub Actions: Deprecating set-env and add-path commands - GitHub Changelog

自分で使っているものの、そこまで頻度が高くないので全然気づかなかった。
dependabot の Pull Request にコメントまでもらったのを今日気づいて、慌てて対応した。

GitHub Actions ではリリース時に node_modules の中身をアップロードしないといけないという悲しい仕様なのだが、リリース作業でやらかして、リリースタグをこっそり作り直すということをした。
夏に Mac から Windows PC に乗り換えたのだが、Windowsnpm install したバイナリをリリースしたのがいけなかった模様。
WSL を常に使う意識付けが必要だった。

リリースした後にもコミットを入れてしまったので、また近いうちにリリースしよう。

Terraform Cloud の View raw log に余計な文字が出力される件

問題

www.terraform.io

Terraform Cloud をサービス開始当初から使っている。

terraform plan の実行ログをコピペするのがしづらい(カーソル状態が定期的にリセットされる挙動で Ctrl + C が空うちされる!) ため、 "View raw log" からログをダウンロードして利用するのが回避策として有効なのだが、ここには一つ落とし穴がある。

それはデフォルトだとログに余計な文字が含まれてしまうことだ。

期待結果は以下のイメージ

# azurerm_app_service_certificate.xxxxxxxx will be created
+ resource "azurerm_app_service_certificate" "xxxxxxxx" {
+ expiration_date = (known after apply)
+ friendly_name = (known after apply)
+ host_names = (known after apply)
+ id = (known after apply)
+ issue_date = (known after apply)
+ issuer = (known after apply)

実際は以下

[1m # azurerm_app_service_certificate.xxxxx[0m will be created[0m[0m
[0m [32m+[0m[0m resource "azurerm_app_service_certificate" "xxxxxx" {
[32m+[0m [0m[1m[0mexpiration_date[0m[0m = (known after apply)
[32m+[0m [0m[1m[0mfriendly_name[0m[0m = (known after apply)
[32m+[0m [0m[1m[0mhost_names[0m[0m = (known after apply)
[32m+[0m [0m[1m[0mid[0m[0m = (known after apply)
[32m+[0m [0m[1m[0missue_date[0m[0m = (known after apply)
[32m+[0m [0m[1m[0missuer[0m[0m = (known after apply)

回避策

サポートに確認したところ、この余計な文字は + などの部分に色をつける装飾のための文字コードだ。

回避策は terraform cli を実行するときのパラメータを変更すること。

環境変数 TF_CLI_ARGS-no-color を追加すれば装飾されなくなる。

参考: Environment Variables - Terraform by HashiCorp

感想

この回避策を取ると通常の Web 上の画面でも装飾されないことになるので、そこが不便になる。
理想を言えば Web 上は装飾あり、ログでは装飾なしのプレーンな形式で確認したい。
つまり terraform cli の挙動ではなく、Web 上で装飾してほしい。
という要望は出しておきましたがどうなるか。

Terraform で Market Place の Azure VM をデプロイするときにやること

Terraform 使い始めてしばらくになるのに知らなかったのでメモを残しておきます。

Terraform 定義

plan block がマストです。

resource "azurerm_virtual_machine" "main" {
  ...

  plan {
    name      = "{Name}"
    publisher = "{publisher}"
    product   = "{product}"
  }
}

storage_image_reference で記載する値と同じようなものを入れることになります。
詳細は Azure Provider のドキュメントを参照ください。

Azure Resource Manager: azurerm_virtual_machine - Terraform by HashiCorp

デプロイ前に実行すること

利用許諾に承諾する必要があります。
Azure ポータルでデプロイするときに画面に表示されるアレですね。

それぞれ以下のコマンドで実行します。

Azure CLI: az vm image | Microsoft Docs

PowerShell: AzureRM.MarketplaceOrdering Module | Microsoft Docs

もちろん該当のサブスクリプションに対して行う必要があるので、そこは注意ですね。

DockerHub で0Byteのコンテナが自動ビルドされた

DockerHub で docker イメージの継続的デリバリを行うために automated build 機能を使っている。
Set up automated builds | Docker Documentation

数年間使い続けているが初めてタイトルの現象を目にしたので記録しておく。

現象

master ブランチ更新時に latest イメージを作成しているのだが、2日前に作成されたイメージが以下の画像。

f:id:khei-fuji:20200927105552p:plain

このイメージを利用しているホスト(Web App for Container) 側のログは以下。

2020-09-27T01:41:08.455Z ERROR - DockerApiException: Docker API responded with status code=NotFound, response={"message":"pull access denied for `organization/repo`, repository does not exist or may require 'docker login': denied: requested access to the resource is denied"}
2020-09-27T01:41:08.457Z ERROR - Image pull failed: Verify docker image configuration and credentials (if using private repository)

パッと見だと認証周りのエラーに勘違いしてしまったが、 docker image が NotFound だった、ということだった模様。

対処

Latest イメージをビルドし直して解決したが、これはプラットフォーム側で解決してほしい。

Cognitive Service を使った Jekyll 製の翻訳サイトを話題の Static Web Apps に載せ替えた

昨日書いた Azure CDN + Blob Static website のサイト、載せ替えたい欲求が高まったので載せ替えた。

今回の変更は Build 前だったのだが、今やるなら話題の Static Web Apps で実装するのがよさそう。というかもう載せ替えたい。

kheiakiyama.hateblo.jp

ホスティング

f:id:khei-fuji:20200525124958p:plain
hosting

これまで Azure CDN + Blob static website だったのが Static Web Apps に変わったので非常にシンプルになった。

デプロイ

f:id:khei-fuji:20200525125018p:plain
deployment

デプロイも構成要素が減った分シンプルになった。
Static Web Apps ではリソース作成時、GitHub Action が作成され、 GitHub の Secret にデプロイ用のキーが登録される仕様なので、それを使ってデプロイされる。

パイプラインは こちら

f:id:khei-fuji:20200525125855p:plain
GitHub - Secret

現在は Preview で課金されないことになっているが、個人サイトで使うには金額次第で元の構成に戻す可能性があるため、前の GitHub Action はファイルを残してある。
Disable にできない仕様のようなので、意味がない Trigger 設定にしておく。
参考: How can I disable a github action? - GitHub Community Forum

つまづいた点

Jekyll でデプロイできない

このサイトでは Jekyll を使っていて、Hugo のチュートリアル を見てデプロイ設定を推察して書いていたが、デプロイできずに Issue 投げて質問して解決した。

How do we use for jekyll? · Issue #27 · Azure/static-web-apps · GitHub

これだと NG(Hugo はこのパターン なのに・・)

        app_location: '/'
        app_artifact_location: '_site'

これで OK

        app_location: '_site'
        app_artifact_location: ''

一応回答の通りに対応したが、それだと app_artifact_location がなんのためにあるのかって気もしていて、たぶんそのうち解決するのだと思う。

感想

Static Site 部分、API 部分どちらも Consumption Plan になりますように。(個人でも払える範囲だといいなあ)

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps ―4本柱による持続可能な組織文化の育て方