おそらくVScodeとの競合だろうと思いますが、Dockerが起動しない時の対応方法です。
アクティビティモニターで、
Dockerのプロセスを強制終了させて、Dockerをクリックすれば起動しました。イメージは正常にDesktopが起動っできている状態の時ですが、起動できない時にはプロセスがもっと少ない状態です。
admin
la vie libre
あまり気にしたことはなかったのですが、Dockerに割り当てられるメモリが少な過ぎれば当然動いて欲しいものも動かないということになりますが、メモリサイズを指定しないでDockerを起動して割り当てられるメモリサイズを確認してみました。
条件はM1MacBook Airでメモリは16GBです。
# free
total used free shared buff/cache available
Mem: 8040052 436668 6207184 352068 1396200 7070628
Swap: 1048572 0 1048572
アクティビティモニターで見ても確かに8GB割り当てられているので、デフォルトではおそらく物理メモリサイズの半分が割り当てられるようです。Linuxで普通に使っていて何ら問題になりそうもないサイズです。
現実的には実メモリが8GBあればDockerの動作に問題は無いというのが一般的な記事に書かれていることですが、それだとデフォルトでおそらく4GB割り当てられてMac側が4GBでは他のアプリの動作が厳しくなりそうですからVMにしろDockerのようなコンテナにしろ実メモリが多くて困ることはありません。
admin
以下の記事で、Intel MacとM1 Macでビルド時間が違うことに気づいたので、条件を同じにして比較。
https://isehara-3lv.sakura.ne.jp/blog/2023/04/23/dockerコンテナからイメージを作成する/
<時間計測の条件>
一度ビルドを完了した状態で、実行ファイルを削除して再度ビルドに要する時間を計測(実際行っていることはリンケージですね)
スクリプトファイルで、
% go build main.go
の前後のタイムスタンプで計測
M1 Mac native build time -> 2 seconds
% ./build.sh
2023年 4月24日 月曜日 13時12分41秒 JST
2023年 4月24日 月曜日 13時12分43秒 JST
M1 Mac Docker container build time -> 11 seconds
# ./build.sh
Mon Apr 24 05:00:53 BST 2023
Mon Apr 24 05:01:04 BST 2023
Intel mac Docker container build time -> 61 seconds
# ./build.sh
Mon Apr 24 04:18:53 BST 2023
Mon Apr 24 04:19:54 BST 2023
Raspberry Pi model B+ native build time -> 118 seconds
$ ./build.sh
Mon 24 Apr 13:05:53 JST 2023
Mon 24 Apr 13:07:51 JST 2023
Intel/M1 Macは他のタスクではほぼ同じパーフォーマンスなので、Intel CPUではarm CPUのエミュレーションが明らかに速度が遅いようで、M1 MacでのDockerだけがクロスビルドの許容内、規模にもよりますが。
admin
誤ってコンテナ削除すると、それまでに適用したアップデートが全て消えるので、コンテナからイメージを作成する方法。
コンテナを停止、docker psで見えない状態、してからたとえば以下のようなコマンドを実行すればrasp32_image_goという名前のイメージが作成されます。作成後はrunでコンテナ(ここではrasp32_go)を作成して内容を確認しておけば大丈夫です。
% docker commit rasp32 rasp32_image_go
<image>
<container>
rasp32コンテナに適用した変更を保存するために、rasp32_image_goというイメージを作成しています。簡単ですね、
必要ならDockerhubにアップロードしておけば共有やバックアップができます。個人で使う分にはDockerhubはバックアップでしかないですが。
共同作業をする対象ならば、historyが見えなくなるので使いづらいでしょうが、個人で使う分にはDcokerfileを使わなくてもこれで十分だろうと思う。
admin
https://isehara-3lv.sakura.ne.jp/blog/2023/04/19/golangアプリは単純にクロスビルドしても動かない(db/
の対応としてとりあえずラズパイ自身でbuildさせましたが、ラズパイModel B+でbuildに必要な時間は、実行ファイルのタイムスタンプからおよそ二時間。これでは実用的ではないので代替え方法を考えるけれども、一番楽そうなのはDockerを使うことでしょう。
自分の環境を汚染させないとか、イメージの配布とかではなく、ラズパイの環境を作るための使用(DockerはM1 Macにインストール、ターゲットのコンテナはraspbian32 OS)です。
多少以前の記事になりますが、以下を参考に実行。raspbianイメージとかは最新版、と言っても2020年度が最新ですが。
https://www.koatech.info/blog/raspbian-on-docker/
・イメージ取得と作成
% wget http://ftp.jaist.ac.jp/pub/raspberrypi/raspios_lite_armhf/root.tar.xz
% docker image import ./root.tar.xz raspbian-stretch-lite:2020
・以下のコマンドでwarningが出る、とりあえずは無視して大丈夫な様子(QEMUは元々Intel CPU用だからか、Apple siliconでも今のところ何とかなってるけど)
% docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
exec /register: exec format error
・コンテナ作成と起動(名前指定)
% docker run -it --name rasp32 raspbian-stretch-lite:2020 bash
・作成しているコンテナを起動するなら
% docker exec -it rasp32 bash
・Golang install
# wget https://golang.org/dl/go1.20.1.linux-armv6l.tar.gz
# sudo tar -C /usr/local -xzf go1.20.1.linux-armv6l.tar.gz
# /usr/local/go/bin/go version (パスが通っていない状態)
・Dockerのコンテナからファイルをクライアントにコピー(例)
% docker cp 21f2c6ce6eb8:/home/pi/hello .
・ディレクトリ指定すればその中全部をコピー(クライアントからコンテナへ)
% docker cp myfare 21f2c6ce6eb8:/home/pi/
コンテナ上のMacの該当ディレクトリを丸ごとコピー(gomodなど含めて)してきてbuild、できた実行ファイルをscpでラズパイに転送して起動するとちゃんと実行できました。実行ファイルの動作確認、最初は定番のハローワールドで確認しています。
エミュレーション(QEMU)なので、速度はMacでbuildするのに比較すると遥かに遅い、それでも二分ぐらいで終わっているからやはりラズパイで実行するよりはほぼ百倍速いから実用的です。
実行ファイルのサイズが微妙に違うのはライブラリの版数違いか、main1のほうがコンテナでbuildしたもの。
コンテナ上のraspbian、
ラズパイのbuild環境としてはおそらくデフォルトだと思う。カスタマイズしたコンテナを作る時にDcokerfileを記述しておけば、再現性確保できます。
admin
Macで開発したアプリをラズパイで動かそうとしましたが、そのままでは動かない。なぜならgormもdbドライバーもcgoを使っている、つまりターゲットのgccを用意してそれを指定しないといけないから。
とりあえず動かすだけなら、すごく時間はかかりますがラズパイでビルド、2時間ぐらい放置してたらビルド完了してました。
実行ファイルを起動すると、Macよりは多少レスポンスは遅いのですがちゃんと動作しています。
<layout.html>
これだけはws://mbair.local:8080/wsをラズパイに変更が必要です。
window.onload = function () {
socket = new WebSocket("ws://mbair.local:8080/ws");
socket.onopen = function () {
append_message("system", "Socket Connected");
};
socket.onmessage = function (event) {
append_message("server", event.data);
};
const send = function (){
socket.send("")
}
setInterval(send, 500);
};
クロス環境をどうするかですが、Dockerがおすすめのようなので、それでやってみます。
メモリ使用状況は、こんな感じです、クライアント一台だけで、
すぐにもう一台増やすと、およそ200KBぐらい増えていますが、この程度では普通には十分です。
admin