はじめに 今日もせっせとlinuxマシンを情報シス業務で日夜触りまくっているネバー・フレンズ・Tです。 今回はみんな大好きUbuntu/Debian系のaptコマンドのデバッグの仕方についてちょこっと書いてみます。 実はaptはデバッグしやすい apt-get source aptして取ってこれるaptのC++のソースコードを眺めていると、ソースコードの要所要所でデバッグ用の仕掛けが入っていることに気が付きます。この仕掛けを利用すると、いろいろ気の利いたところでデバッグ出力をさせることができますので、なにかaptの問題に遭遇したらちょこっと試してみるのも良いかもしれません。 まずはaptの設定内容を見る aptにどういった設定がなされているか？はデバッグ開始前に確認しておいたほうが良いです。こんな時に便利なコマンドとしてapt-config dumpがあります。 $ apt-config dump APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; ...後略... aptのソースコードでも、apt-config dumpで出てくるような形式の文字列でフラグのON/OFFを確認しています。 実際の例： _config->FindB("Debug::pkgAcquire"... なお、ソース中のこのフラグ確認部分ですが、オプションの名前については大文字小文字を無視した判定(stringcasecmp():apt-2.5.3/apt-pkg/contrib/strutl.cc)をしているので、大文字小文字が異なっていても、同じオプションとして扱われます。 apt updateの処理の様子を見る 次は試しにapt updateがどこから何を取ってくるか？を確認してみます。 まずはコマンドラインオプションである、--print-urisをつけると、その一部をうかがい知ることができます。 $ apt update --print-uris 'http://deb.debian.org/debian/dists/sid/InRelease' deb.debian.org_debian_dists_sid_InRelease 0 'http://deb.debian.org/debian-debug/dists/sid-debug/InRelease' deb.debian.org_debian-debug_dists_sid-debug_InRelease 0 'http://deb.debian.org/debian/dists/testing/InRelease' deb.debian.org_debian_dists_testing_InRelease 0 'http://deb.debian.org/debian-debug/dists/testing-debug/InRelease' deb.debian.org_debian-debug_dists_testing-debug_InRelease 0 'http://deb.debian.org/debian/dists/sid/main/source/Sources.xz' deb.debian.org_debian_dists_sid_main_source_Sources 0 'http://deb.debian. .

オブザーバビリティー? “observability” という言葉をよく聞くようになりました。以前よりは、ですが。長くて、カタカナで書いても正しく書けたか自信がないです。上に書いたのも、変換をミスったりして二度ほど書き直しました。そもそも手元の IME で変換できていないような気がしています。Internationalization を i18n と書くように、o11y という表現もあるようですが、もう何がなんだかです。 意味合いとしては、システムの “見える化” を進めようよ、ということと捉えています。サーバーで動くシステムが複雑になると、どんどん内在する問題が見えにくくなっています。様々なデータを集めて可視化することで問題の早期発見やパフォーマンスの改善に活用していきたいところです。 マイクロサービスのボトルネック…? 機能を細分化するメリットももちろんありつつ、問題が起きたときにその調査が難しくなるようなことも多いです。 たとえばある API が妙に時間がかかっているというときに、API 処理の CPU 時間が原因なのか、そこからの DB 処理待ちなのか、ファイル書き込みが遅いのか、… などなど、原因特定に時間がかかることがあります。本番環境でしか発生しないようなことも多く、そういった要素が絡み合ってデバッグの難易度を高くします。 今回は、Open Telemetry の Trace 機能を使って、どの処理にどれくらいの時間がかかっているのかをどのように視覚化できるか見てみようと思います。今回 GCP は使いますが Cloud Run などの GCP で利用可能なものに限ったものではなく、オンプレ等で動くカスタムアプリケーションにも仕込める想定でやってみます。プログラムへの組み込みが必要になってはしまいますが。 そして相変わらずわたしの都合で例は nodejs です。注意点として、node 向けの Open Telemetry の library は完成度が他言語に比べてイマイチな印象で、かつ変更も早いようです。ともあれ言語の選択要件はシステムによってさまざまですので、ここでの例は “例” としてご参照いただければと思います。 サンプル！ 忙しい人のためにしては前置きが長くなりすぎました。ここで一気にスピードを上げて、いなきりサンプルコードを出して完結したいと思います。 const opentelemetry = require("@opentelemetry/api"); const { NodeTracerProvider } = require("@opentelemetry/sdk-trace-node"); const { SimpleSpanProcessor } = require("@opentelemetry/sdk-trace-base"); const { TraceExporter } = require("@google-cloud/opentelemetry-cloud-trace-exporter"); const provider = new NodeTracerProvider(); const exporter = new TraceExporter(); provider.

はじめに 昨今UEFI対応BIOS+SecureBootネタに執心のネバー・フレンズ・Tです。 Linuxを相手にしたUEFI対応BIOS+SecureBoot仕様の操作の練習（試行錯誤）を安全にやりたい方向けに手元の仮想環境(kvm)で実際にUEFI対応BIOSを動かし、SecureBootを有効にしてDebianを対象にブートの設定だけ手組してみることを語ってみます。 こちらに慣れておけば、以降はお好きにUEFIの実験ができるようになり、理解が進むのでは？と思ってます。 UEFI対応BIOS+SecureBoot(Debian デフォルト起動編)の概略図とEFI Variable いままでレガシーBIOS Bootばかり触ってきた人にありがちなのですが、巷のUEFIの解説やLinuxのUEFI Bootの解説、断片的なUEFI関係のblogやwikiを見て、あまりに断片的な内容が多いためか理解するのに心折られた方も多いかと思います。かくいう自分もその一人で、わけがわからないよ！と正直思ってました。UEFI対応BOISとSecureBootの起動についてぜんぜんわからない俺はブートを雰囲気でやっている、ということから少しは抜け出してみます。 まずは、Debianの起動からです。shim-unsignedパッケージのソースコード、及び、手元のDebian unstableの設定ファイルから、概略ですが、図に起こしてみました。 図中、EFI VariableがUEFI対応BOISのブートを制御する変数群となります。図に書ききれないため省略しておりますが、これら変数にはもれなくGUIDというIDが付属しており、このGUIDと変数名のペアで参照することになっています。実際にBootOrder変数を例にLinuxから見てみます。Linux環境はDebian(unstable)となります。 $ sudo apt install efivar $ efivar -l | fgrep -i bootorder 8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOrder $ efivar -L | fgrep 8be4df61 {8be4df61-93ca-11d2-aa0d-00e098032b8c} {global} efi_guid_global EFI Global Variable 8be4df61-93ca-11d2-aa0d-00e098032b8c-というのがGUIDであり、分類としては、EFI Global Variableに所属していることを示しています。早速中身を確認してみます。 $ efivar -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOrder GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c Name: "BootOrder" Attributes: Non-Volatile Boot Service Access Runtime Service Access Value: 00000000 07 00 02 00 05 00 01 00 06 00 04 00 03 00 |.

ホシイです。こんにちは。 あまりこういうことばかりを書いていると怒られそうですが、やっぱり有料ライセンスが必要なソフトウェアって使い始めるのに敷居を感じてしまいます。でも、本格的にチームに導入する前に container での開発をしばらく検証したいとか、年に数回しか使わないからライセンス費用を抑えたいという場合もあるかと思います。 以前に、Docker push での事故を防ぎたい という記事を書きました。このときは有料ライセンスがあることを前提に、push するときには気をつけよう！というのが主題でした。 Docker CE は Docker の Community Edition で、Linux で Docker を無料で使えます。今回は、Docker が業務になじむかわからないけど、まずは試してみたいな… という場合でも迷わずすぐにはじめられるように、WSL2 + Docker CE を使って container を利用できる環境構築をしてみましょう。 ※ 今回は Windows 10 を使用しています。Windows 11 をお使いのかたは (ほぼおなじだと思いますが)、適宜読み替えなどおねがいします。 まずは WSL2 を使えるようにする PowerShell などを使い、WSL を有効にし、また、(WSL1 ではなく) WSL2 を default に設定しておきます。後者は必須ではありませんが、今回の内容では WSL1 では動かないハマりポイントがあるので、他で WSL1 をメインに使われているとかでなければ設定しておくのをおすすめします。 PS C:\> wsl --install PS C:\> wsl --set-default-version 2 次に、Microsoft Store から以下二点を install しておきます。 Ubuntu 22.04 一度起動して install を完了しておく (一般 user をつくる) (おすすめ) Microsoft Terminal を入れる Ubuntu は MS Store に複数のバージョンがありますが、記事作成時点で最新の 22.

はじめに Linuxを今時のPCに入れて使ってるのにUEFI+SecureBoot経由じゃないのは小学生までと思うネバー・フレンズ・Tです。今回は早速SecureBootを使うようになって困った件と回避策について語ってみます。 SecureBootではdyndbg機能が動かない!? なにかのデバイスをLinuxマシンに追加しようとして、うまく動かなくて大ハマリした経験はLinux使いの人だと誰しもあると思います。弊社でも山ほどの物理マシンに搭載したLinux機がありますので、そういう問題に直面することがあります。まあ、大体はベンダのサポートの皆様にヘルプを要請するとなんとかなることが多いですが、なんでもサポート契約のあるような機材ばかりと思うなよ？という状況に遭遇することがあります。例えば一時的に会社の民生品をつないで、動作させなければならない場合などでしょうか。 ここで、外付けデバイスの調子が悪い場合に役に立つのがLinux kernelの持つデバイスドライバに搭載されているデバッグ用のログ出力(dyndbg機能) となります。ところが、今時のUEFI+SecureBootの環境と、特定のディストリビューションの組み合わせでは、dyndbg機能が封じられてしまっているという問題に直面することがあります。 dyndbg機能が動かないことを確かめる 実際にUEFI+SecureBootで起動したDebian unstableでやってみます。現在SecureBootが有効か？をmokutilで確認してから、kernelのnet/ipv4/ping.cのデバッグ用ログを有効化してみます。 $ uname -a Linux debian-sid 5.16.0-4-amd64 #1 SMP PREEMPT Debian 5.16.12-1 (2022-03-08) x86_64 GNU/Linux $ lsb_release -dirc Distributor ID: Debian Description: Debian GNU/Linux bookworm/sid Release: unstable Codename: sid $ sudo apt install mokutil $ mokutil --sb-state SecureBoot enabled Debianで、SecureBootが有効ですね。では早速デバッグ用ログを有効化します。 # echo 'file net/ipv4/ping.c +p' > /sys/kernel/debug/dynamic_debug/control bash: /sys/kernel/debug/dynamic_debug/control: Operation not permitted root成りしたのに操作拒否られるってどういうこと！？このままでは納得行かないので、早速ログにヒントが無いかを確認します。 # journalctl | tail ...中略... Mar 06 14:32:58 debian-sid kernel: Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.

log を活用してシステムの可視化を進める 今回は Observability に関連する記事です。Observability といえば、以前にも custom metrics や trace を送信する方法を調査しました。 今回は「アプリケーションに手を入れるのはしんどいのだが、log にはすでにある程度の情報を吐いているので、それを活用してシステムの可視化ができないだろうか」というシナリオを想定してできることを見てみます。 GCP では Logs-based metrics という機能がありまして、かんたんに言うとこれを使ってみましょう、という内容です。 前提として、GCP Operations Suite (旧 Stackdriver) に log を送信していることとします。 Logs-based metrics を設定してみる 今回は、API サーバーが以下のような log を出力している想定としましょう。 2022/03/15-09:30:41 - API call [sqex.api.user.readInfo] - 2022/03/15-09:30:42 - API call [sqex.api.user.readInfo] - 2022/03/15-09:30:43 - API call [sqex.api.user.writeInfo] - httpd でいう access_log のようなもので、日時と実行した API 名を log に出しています。一般的に、こういったものを出力するのはよくあることだと思います。 上記リンクをはったページにもやりかたがありますが、GCP web console の Logs-based Metrics 機能に飛ぶと、あたらしく metrics を作成することができます。 ここで、上記に例示しました log 出力に対して metrics を作成してみましょう。

はじめに ネバ―・フレンズ・Tです。Windows10+WSL2を使っていてGUIを無性に使いたくなるときってありません？ 今回はWindows10+WSL2+ubuntu 20.04+VNC+docker(moby版)でdebian unstableのGUI環境を動かしてはまったことを書きます。 なお、未確認ですが、現在最新のubuntu 22.04では本ブログで語る問題は全部治っているハズ…なのでそこはご了承ください。dockerdまわりではまったらこうやってデバッグすることもある…ということで生暖かくみていただければと思います！ Windows10+WSL2+ubuntu 20.04にdockerを手早く用意 Windows10+WSL2上のubuntu 20.04にdockerをさらっと用意します。apt一発でインストール完了、systemdを起動してsystemdのpidにnsenterしてからdockerdを起動するだけなので、超簡単ですね！1 $ uname -a Linux your-machine 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux $ lsb_release -dirc Distributor ID: Ubuntu Description: Ubuntu 20.04.3 LTS Release: 20.04 Codename: focal $ sudo apt install systemd docker.io daemonize util-linux $ sudo usermod -a -G docker $USER $ sudo daemonize /usr/bin/unshare --fork --pid --mount-proc /lib/systemd/systemd --system-unit=basic.target $ SYSTEMD_PID_OUTER=$(ps -auxww | fgrep '/lib/systemd/systemd' | fgrep system-unit | fgrep -v unshare | awk '{print $2}' ) $ sudo nsenter --target $SYSTEMD_PID_OUTER --all su - $LOGNAME $ ps -auxww | fgrep '/lib/systemd/systemd' | fgrep system-unit | fgrep -v unshare root 1 0.

前置き ホシイです。web backend のようなシステムの開発には、container は必要不可欠な技術になるまでに存在感を増しています。container というとパッとつくってすぐに壊すというイメージがありますが、試行錯誤をサイクルさせる開発環境としての使い勝手はどうでしょうか。 Visual Studio Code (以下 VS Code) の devcontainer は、開発環境を宣言的に整え・共有し、便利に利用できる、とても強力な機能です。 今回はこの devcontainer の布教をします！ 今更か… という感もありますが、めんどうでまだ触れてない・どんなものか触ってかんたんに知りたい、という需要は意外とありそうに思われましたので、最速でメリットを感じることを目的にご紹介したいと思います。 前提条件 以下、install & setup しておきます。 Visual Studio Code Docker Desktop (Docker Desktop であることは必須ではありませんが、ここでは単純化のためにこうさせてください) 手順 VS Code を起動し、作業用 folder (directory) を開く メニューから “File” > “Open Folder …” を選択します。 folder 選択 dialog が開いたら、あたらしく folder を作成し、その場所を開きます。 devcontainer の設定を追加 command palette を開き (Ctrl + Shift + P / ⌘ + Shift + P)、以下のように進めます。 ”Remote-Containers: Add Development Container Configuration Files…” を選択 option の選択に進むので、Ubuntu > “ubuntu-22.

はじめまして、スクウェア・エニックスのBと申します。 Linux上で良く分からない内に使用している方が多いであろう機能として、D-Busがあります。 D-Busは、プロセス間通信を実現する方法としてメッセージバスを提供してくれます。 名前からデスクトップ用途でしか使用することがないと思われる方もいるかもしれませんが、サーバ用途でも様々な箇所で使用されています。 例えば、SELinuxの関連でsetroubleshootというサービスがD-Busを利用しています。 これは、ポリシ違反に関する記録をもとに、その分析をおこなってくれるものです。 過去に私は負荷試験の過程で、setroubleshootを暴走させてしまいました。 setroubleshootが悪い訳ではなく、ポリシの調整不足から、大量の違反をsetroubleshootに分析させ続けてしまう状況にしてしまいました。 そして、それを停止するために、setroubleshootの仕組みを調査しました。 その過程でD-Busの設定や動作状態についても簡単に確認する必要がありました。 ここでは、その際に活用したD-Bus用ツールによるD-Busの確認方法について主に取り上げます。 setroubleshoot D-Busの確認方法について紹介する前に、setroubleshootについても簡単にではありますが説明します。 setroubleshootはその名の通り、SELinuxに関するトラブルシュートを補助してくれるサービスです。 少なくとも、Red Hat Enterprise Linux 8では最初から裏で稼働しています。 setroubleshoot用のツールである sealert による情報の出力操作とその例です。 ポリシ違反内容やその回数、ポリシの修正方法等を比較的分かりやすい形式で表示してくれます。 $ sealert -l '*' # 出力例: コンテナ内からホスト上にディレクトリ /home/testuser/tmp を作成しようとした場合 SELinux is preventing /usr/bin/coreutils from write access on the directory labeled user_home_dir_t. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that coreutils should be allowed write access on directory labeled user_home_dir_t by default. Then you should report this as a bug.

はじめに こんにちは。ネバ―・フレンズ・Tデス！ WSL2便利ですね！Windows10を利用しなければならない環境で、なんとかしてLinuxの環境を手元に置きたいという願いは人類不変の願いです。 今回はWSL2でauditdが動いてくれなかったので、無理矢理auditdを動かしてみた件を書きます。 WSL2でaudit.logを取りたいっ WSL2のubuntu 20.04で、libseccomp2を活用したプログラムを検証していました。ここで、seccompで引っ掛かったのはどのsystem callか？を調べる必要が出てきました。 どうもこの時のログの出力はaudit系の出力先にでるそうです。では、手元のWSL2でauditdが動けば/var/log/audit/audit.logにログを集めれるかも？と思いWSL2でauditdを動かしてみました。 WSL2のubuntu20.04だとauditdは動かない… 早速auditdをWSL2のubuntu20.04で動かそうとしました。 $ uname -a Linux your-machine 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux $ lsb_release -a Distributor ID: Ubuntu Description: Ubuntu 20.04.3 LTS Release: 20.04 Codename: focal $ sudo service auditd start * Starting audit daemon auditd [fail] failとありますので、動いてくれません… CONFIG_AUDITがOFFなのが怪しい 　WSL2のubuntu20.04ではjournaldすらも動いていないので、そのままではシステムに関するログは出ません。なぜauditdが動かないのかはログに頼らず調べる必要があります。 $ sudo /sbin/auditd -n -f Config file /etc/audit/auditd.conf opened for parsing ...中略... distribute_network_parser called with: no Error - audit support not in kernel Cannot open netlink audit socket The audit daemon is exiting.

はじめに ネバ―・フレンズ・Tです。こんにちわ。 大人の事情により、新しいLinux環境でどうしても古いpythonを動かしたいという件ってありませんか？ 私は普通にあります。ここでは、最新の環境(debian unstable)にて、python3.6を動かそうとしておおはまりした件をお話しようとおもいます。 python3.6がSegmentaion fault pythonのいろいろなバージョンが欲しいときいろいろなpythonの仮想環境を作る方も多いと思います。自分は主にpyenvを使っています。 今回どうしてもpython3.6の環境を用意する必要があり、以下のように最新のOSであるところのdebian unstableへインストールを試みました1。 $ lsb-release -a Distributor ID: Debian Description: Debian GNU/Linux bookworm/sid Release: unstable Codename: sid $ gcc -v ...中略... Supported LTO compression algorithms: zlib zstd gcc version 11.2.0 (Debian 11.2.0-16) $ pyenv install -k 3.6.15 Downloading Python-3.6.15.tar.xz... -> https://www.python.org/ftp/python/3.6.15/Python-3.6.15.tar.xz Installing Python-3.6.15... BUILD FAILED (Debian unstable using python-build 2.1.0-12-g5963dc4f) Inspect or clean up the working tree at /home/yours/.pyenv/sources/3.6.15 Results logged to /tmp/python-build.20220222021843.38052.log Last 10 log lines: if test "xupgrade" !

ホシイです。本日は git の小ネタをひとつ。 git commit されているものがいつもそのまま動くとは限らない 便利 script を git clone して、そのまま実行！したら、しょうもないエラーに … といったことは残念ながら、めずらしいことではありません。 commit されているものがいつもただしいなんて、いつから錯覚していた…? なんて、よくあることです。レビュアーを責めても時間は返ってきません。 たとえば設定ファイルを yaml で書いていたとして、その yaml に syntax error が残ったまま commit & push してしまった、なんていう経験はないでしょうか? こういった問題は作業者の気の緩みによって起きるものである、気合で解決だ！ …というのは難しいものです。 commit 前にチェックしよう、自動で。 git には様々なタイミングでかんたんに hook 処理を追加することができます。git init された場所であれば、.git/hooks/ にすでに、いくつも sample を見つけることができます。 たとえば .git/hooks/pre-commit.sample の中身を見ると、sh script でいくつかのチェックをして、失敗したときには exit 1 すればいいらしいことがわかります。 pre-commit という名前なのですから、きっと commit 前に走って、失敗すれば commit も抑制されるのでしょう。今回の目的に合いそうです。 試してみよう .git/hooks/pre-commit という名前で以下のような中身のファイルを作成しておきます。 #!/bin/sh exit 1 これで、なんでもいいので試しに commit してみましょう。 $ git commit fatal: cannot exec '.

はじめに 今日もクラウドサービスにサーバ作っているネバー・フレンズ・Tです。 VPN利用がいろいろなところでカジュアルに叫ばれている中、VPNってどう動くんだろう？と思ったことはないでしょうか？自分もVPNがどう動くのかを、むつかしいことは抜きにもっと手軽に知りたい！と思ってました。 今回はLinuxのtapデバイスを操って、AWS Client VPNやその他のVPNのソフトウェアを一切使わず、AWSに簡易VPNを手組みで建てて手元のLinux機と通信させることを試してみます。実は大仰なソフトウェアを使わなくても実はVPNってとっても簡単だね！ということを感じていただければうれしい次第です！ VPNって重要だね！ いろいろな環境から遠くのコンピュータ資源を利用する手段としてVPNがあります。最近は多様性の世の中から、いろいろな事情でVPNをつかわざるを得ない機会も増えてきている状況です。通信の中身を見られないようにしてまるでLANをつなげているような感覚で遠隔地の計算資源を操作/通信できるわけですから、そりゃ便利です。いまだとリモートワーク全盛ですので、VPNの恩恵なしにはCOVID対策と商売も両立できませんでした。 ただ、VPNのマニュアルを見ると、なんとなくどこもかしこも複雑そうですよね！だいたい複雑そうでブラックボックスな場所って、ちょっと放っておくと闇の使いからの脅威が入りやすい場所となってしまうのは、世間のお約束です。もし、使っているVPNが信用できなかったら…と思いをはせると、顔から冷や汗が吹き出し、心臓がキュンキュンするーっ！という気分になる人も多いと思ってます。自分も、まさか普段使っているVPNに闇の使いへのバックドアが開いていたら…と思うと、いろいろな心配事が交錯して夜も眠れません。 でも、安心してください！いざとなったら自分が信用できる方法だけ使っても、手軽にVPNが作れることを知っておけばいいのです！ 原理は簡単 VPNの接続の様子を図にしました。 遠隔地のLANを何らかの方法でユーザの機材をつないでしまえればVPNはできてしまうということがわかれば、もうわかったも同然です。 実は接続先に端末ログイン可能なLinuxマシンが１台あれば、これとユーザの機材をネットワークとしてつなぐことで、あっという間にVPNの出来上がりです。こういった用途に便利なのはlinuxのtapデバイスとなります。 tapデバイスとは 一番わかりやすい説明はwikipediaのTUN/TAPとなります。読んでのごとくで、tapデバイスを作ると、こちらはまるでイーサーネットケーブルの端子のように扱えるようになります。ここに何らかのプログラムでパケットデータそのものを流し込むと、あら不思議！tapデバイスを作ったLinux機はここからやってきたパケットデータをネットワークから送られてきたパケットデータそのものと思い込んで、うっかり通常のTCP/IP通信としてあつかってくれます。 　というわけで、先の図のユーザのマシンと、リモートのLinuxの両方にtapデバイスをおき、tapデバイス同士の間で、データを相互にそのまま流すことができれば、VPN通信ってできちゃうのでは？と思ったあなたはさすがです！ やってみた 理論上やれるなら、うっかりやってしまいたくなるのはエンジニアのSaGaです！やってしまいましょう！ 今回はよくあるAWSのEC2を置いたシステムの例を用意して、ここにVPNを即席に手組して用意するということをしてみます。例としてAWS(us-east-1)に置き、ローカルPCは日本においてssm経由でログインできるようにしておきます。 あとでssm経由のログイン経路をVPNの通信ルートとしてそのまま活用します。何か双方向に通信さえできれば、VPNだって簡単さ！ということを実感いただければと思ってます。 今回作成のAWSのEC2を置いたシステムの例は以下の図のとおりです。copyright-aws terraformソース(リンク飛ばない人は「付録: terraformソース付録」の章までスクロール）： terraform.tf ec2.tf key_pair.tf 作成したら早速日本にあるローカルマシンからssmでログインしてログインができ、sshもssm経由で接続できることを確かめます。ここではwsl2(ubuntu 20.04)を利用しています。"(local pc)“とあるのは日本の手元にあるPCであり、"(remote linux)“とあるのはus-east-1(北米バージニア）にあるサーバとなります。 (local pc)$ uname -a Linux localmachine 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux (local pc)$ lsb_release -dirc Distributor ID: Ubuntu Description: Ubuntu 20.04.4 LTS Release: 20.

はじめに Windows Subsystem for Linux (WSL) はWindows環境で気軽にLinux環境を実現でき、便利なものです。 Linuxのコマンドを気軽に実行できたり、Hyper-V同様にDocker Desktop for Windowsのバックエンドに指定できたりと便利な一方、WSLを使っているからこそ直面する問題もあります。 本稿では、私が直面した問題についてまとめました。 ※ WSLは厳密にはWSL2とWSL1の2世代ありますが、ここではWSL2を対象にしています。 DNS設定をカスタマイズしたい WSLのデフォルト設定では、WSL用に作成された仮想インタフェースがDNSサーバに設定されています。 以下、PowerShell上の操作は PS > から、WSL上のシェルの操作は $ から記載することとします。 また、WSL上で扱うディストリビューションはUbuntuを例にしています。 # Windows上 PS> ipconfig /all # より抜粋 イーサネット アダプター vEthernet (WSL): 接続固有の DNS サフィックス . . . . .: 説明. . . . . . . . . . . . . . . . .: Hyper-V Virtual Ethernet Adapter IPv4 アドレス . . . . .

Cloud Monitoring で Custom Metrics? GCP を使っていると、使っているリソースによって、たとえば GCE instance であれば CPU 使用率などの metrics が追加の設定無しで利用可能になっており、すぐに dashboard をつくって値を見ることができ、非常に便利です。 これら標準で用意されている metrics と同様に、ユーザー定義の metrics もある程度の手間で利用でき、用途によっては非常に便利に活用できます。 今回はそんな例をひとつつくり、可能性を探ってみたいと思います。 metrics 送信を実装する 今回は こちら の例をほとんどそのまま使います。わたしが慣れてて楽だからという理由で nodejs runtime を使います。 Monitoring 用の module を install して… npm install --save @google-cloud/monitoring 以下ほとんど上記サンプルそのままですが一部だけ、label などをそれっぽく変えています。 後で使う https module も宣言しておきます。 const https = require('https'); const monitoring = require('@google-cloud/monitoring'); const client = new monitoring.MetricServiceClient(); async function writeTimeSeriesData(v) { const dataPoint = { interval: { endTime: { seconds: Date.

概要 継続的インテグレーション、継続的デリバリー（CI/CD : Continuous Integration /Continuous Derivery)を実現するためのツールの1つであるConcourseについて、筆者が特にパイプラインを構成するアーキテクチャが面白いと思ったのでまとめてみました。 Concourseとは Concourseとは、継続的インテグレーション、継続的デリバリー（CI/CD : Continuous Integration /Continuous Derivery)を実現するためのツールの1つです。 公式ドキュメントでは、 設定がソースコードのように扱える YAMLファイル形式 パイプラインの処理の流れが可視化される 処理の流れがグラフ構造としてWeb UI上に表れる 再現性があり、デバッグも容易なビルド あらゆる処理がコンテナ上で実行されていて、専用CLIツールを用いてコンテナ内に入って検証できる（例えば失敗したビルドの原因の調査など） などが特徴としてあげられています。 今回はその中でもConcourseのパイプラインを構築する上で重要な、 「Resource」という概念が面白いと思ったのでまとめてみます。 Concourseにおけるパイプライン Concourseにおいて、パイプラインは以下の要素で構成されます。 Job 複数のTask、及びResrouceの入出力の組 Task 実際の計算処理（例：ソースコードのビルドなど） Resource Concourse内外の入出力を表すオブジェクト 特に私が面白いと感じているのはこのResourceの存在です。 Concourseのドキュメントでも触れられているのですが、Concourseにはいわゆるプラグインのようなシステムではなく、代わりにそのパイプラインで注力したい さまざまな入出力をResourceとして抽象化 しています。 Concourse does not have a complex plugin system. Instead, it focuses on a single strong abstraction: resource, which are implemented by resource types.

ホシイです。Docker Desktop、便利ですよね。 しかし、便利すぎるがゆえに問題になったり、そのために使えなくなったりしてしまったらたいへんです。普段から確認をしておきたい、というのが今回の趣旨です。 Docker Desktop を sign in ありで使いたい? August 31, 2021 (January 31, 2022 まで猶予期間でした) より、Docker Dekstop の Windows 版と macOS 版は、一定の条件下の利用で有料ライセンスが必要になりました。 さて、Docker account で sign in した状態で docker を使うに際し、気になることがあります。DockerHub に “間違って” image を公開しちゃったりしないでしょうか? わたしは業務では GCR (gcr.io) を利用することが多いので、image name には gcr.io/… といった指定をつけて運用していますが、たとえばこれをつけ忘れちゃったりしたらどうなるんでしょう? 最近は手元にテスト環境をつくるようなツール類を container を使って用意していて、docker をふだん使わないメンバーにも使ってもらっていたりすることから、不意の操作で意図せず image が公開されてしまった… というような事故が起きないようにしておきたいです。 秘密情報が含まれた container image が誤って公開状態で DockerHub に upload されてしまうと、情報セキュリティの問題になってしまいます。 そこで、認証と repository の状態によって push の挙動がどのようになるか実験してみました。 以下、Organization に所属した Docker account を使って検証しています。 問題がないケース 存在しない image repository への push は deny されます ❯ docker push test Using default tag: latest The push refers to repository [docker.

はじめに みなさんこんにちは。情報システム部のネバー・フレンズ・Tです。最近はブロックチェーンもはじめました。 ここでは自分が担当した技術面で面白かった件を、問題の無い形に変えて（伏せたり、一部フィクションにしたりしてw 1 )、カジュアルにお送りします。 スクエニ情シスの実際の業務の出来事をベースにしてますので、その雰囲気を十分に感じていただければと思います！ ではゆるゆると、どぞー。 はじまりはいつも… 「とあるpython3のコマンドが、エラーを起こして困ってる」という相談がslackで来ました。みんな大好きpython3。こちらについての相談です。 スクエニの情シスは、社内・お客様サービス用のLinuxサーバも、あらゆるサービスのゲームのサーバも担当します。そのためたくさんの構築・運用・トラブルシュート・技術相談対応・技術評価実施と日夜向き合っています。インストールしたソフトウェアでなにか不具合があると、サービス側の開発スタッフさんらと一緒に解決策を練るのも良く行われます。 ただ、不具合があっても、そのままシュバババっと解決して&俺強えぇぇーっ!というラノベばりの展開だと最高ですが、そんなわけないです。slack/zoomその他今時のリモートワークで人気のITツールを駆使して、落とし所を開発側スタッフさんと泥臭く探るということも多いです。とにかく問題を解決することが最優先なので、「高いハードルは、くぐってしまえ！」という解決策も大歓迎です!! 今回は… pylint付属のpyreverseコマンドです。このツール、ご存じない方にお伝えするとpythonのプログラムのクラス相関図を自動で解析して図示するというツールです。人の書いたpythonを保守担当したりするとクラス相関の掌握がしやすくなるので、大変便利なツールです。 $ sudo apt install pylint graphviz lsb-release xdot $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 11 (bullseye) Release: 11 Codename: bullseye $ pylint --version pylint 2.7.2 astroid 2.5.1 Python 3.9.2 (default, Feb 28 2021, 17:03:44) [GCC 10.2.1 20210110] $ pyreverse -AS -m y logging $ ls classes.dot packages.dot $ xdot classes.

こんにちは、はじめまして。 スクウェア・エニックスのホシイと申します。 この度わたしたちは、ここで、技術系のブログを公開できることになりました！ 制作に参加してくれてているパーティーメンバーをはじめ、ご理解・ご協力をいただいた皆様に感謝します。 そして、さっそく読んでいただいているみなさま、ありがとうごさいます。 このブログについて コロナ禍以来、以前のように物理的に集まるイベントが催される機会がぐっと減り、そういった場でのカジュアルな技術者同士のコミュニケーションの機会もまた少なくなってしまいました。 ただいっぽうで、オンラインでのコミュニティやイベントが発達し、新しい方面での出会いが増えたりもしています。 そのようにして社外のかたとお話させていただく中で、スクエニの中でもいろんな人がいろんな仕事をしていることを、より広く知っていただけたらと思うことがありました。 ゲーム開発に関する話題は注目を集めやすく、外部での発表も多くあります。そのいっぽうでスクエニ内では他にも多くの業務でたくさんの人が働いていて、ゲーム業界以外のエンジニアのかたともたくさんの共通点があります。ここではその隠れがちな面からもすこし発信をすることで、少しでも共感してもらえたらうれしいです。 記事の内容は、(タイトルにも “ITエンジニア” と入っていますように) 巷でとにかく IT と名のつくものに触れる現場であればよく見られる、こまごました事柄を中心としたものになっていく予定です。 が、そのうちちょっと大きめのものや、すこし趣向を変えたものにもチャレンジしていけたらとも思っています。 ここの記事が、すこしでもみなさまのお役に立ったり、息抜きになったりするとうれしいです。 また、オンラインでもリアルでも、イベントの場などでお会いした際には、ここの話題でぜひお声かけいただけるとうれしいです！ それでは、おたのしみください！