[{"content":"","date":"20 5月 2026","externalUrl":null,"permalink":"/tags/ansible/","section":"Tags","summary":"","title":"Ansible","type":"tags"},{"content":"","date":"20 5月 2026","externalUrl":null,"permalink":"/tags/grafana/","section":"Tags","summary":"","title":"Grafana","type":"tags"},{"content":"","date":"20 5月 2026","externalUrl":null,"permalink":"/tags/hpc/","section":"Tags","summary":"","title":"HPC","type":"tags"},{"content":"I cleaned up an Ansible playbook for provisioning a small Ubuntu-based Slurm cluster and put the sanitized version on GitHub.\nRepository:\nshota-ke/slurm_ansible The playbook started as infrastructure code for a local lab environment. Before making it public, I removed site-specific inventories, host variables, generated hardware facts, SSH keys, Munge keys, local environment files, and old reference material. The repository now keeps those files out of Git and includes a Docker Compose environment for validating the roles safely.\nScope # The repository provisions:\na Slurm controller, CPU and GPU compute nodes, Munge authentication, SlurmDBD accounting, Prometheus, Grafana, Node Exporter, optional DCGM Exporter for GPU telemetry. The useful part is that the same Ansible structure can be tested locally before touching real machines.\nDocker validation # The local test environment can be started with:\ntask dev:up task dev:deploy task status ENV=docker The Docker inventory creates one controller and three compute containers:\nNode Role controller Slurm controller, SlurmDBD, Prometheus, Grafana gpu1 example GPU compute node gpu2 example GPU compute node cpu1 example CPU compute node The Docker-only SSH and Munge keys are generated under secrets/, which is ignored by Git.\nSlurm resource view # I also restored a small reference command named sres, which prints a compact view of Slurm node resources. In the Docker cluster, it produced:\n┌───────────┬────┬─────────┬──────────────┬──────────────────────┐ │ node │ ST │ CPU │ memory │ CPU-JOBS │ ├───────────┼────┼─────────┼──────────────┼──────────────────────┤ │ cpu1 │ 🐟 │ 6 / 6 │ 23 / 23 GB │ CPU free │ ├───────────┼────┼─────────┼──────────────┼──────────────────────┤ │ gpu1 │ 🐟 │ 6 / 6 │ 23 / 23 GB │ CPU free │ ├───────────┼────┼─────────┼──────────────┼──────────────────────┤ │ gpu2 │ 🐟 │ 6 / 6 │ 23 / 23 GB │ CPU free │ └───────────┴────┴─────────┴──────────────┴──────────────────────┘ Monitoring # Prometheus is configured to scrape the controller and compute nodes.\nPrometheus targets in the Docker validation environment. Grafana is provisioned with dashboards for the Slurm cluster and node metrics.\nGrafana Slurm dashboard rendered from the Docker validation environment. Keeping the Grafana provisioning files and dashboard JSON in Git makes the monitoring layer easier to reproduce after rebuilding the environment.\nCleanup checklist # The highest-risk part of sharing an Ansible repository is usually not the playbook itself, but the surrounding local state. I checked for:\nSSH private keys, copied public keys from real hosts, known_hosts, Munge keys, real host variables and IP addresses, .env files, internal URLs embedded in dashboards, old reference files. The repository also has a security and publishing checklist.\nReferences # Repository: shota-ke/slurm_ansible Ansible documentation Ansible playbooks Ansible roles Slurm Quick Start Administrator Guide Slurm accounting and resource limits Slurm GRES scheduling Docker Compose documentation Taskfile documentation Prometheus getting started Prometheus Node Exporter guide Grafana provisioning documentation NVIDIA DCGM Exporter documentation ","date":"20 5月 2026","externalUrl":null,"permalink":"/notes/slurm-ansible-playbook/","section":"Notes","summary":"","title":"Notes on a Small Slurm Cluster with Ansible","type":"notes"},{"content":"","date":"20 5月 2026","externalUrl":null,"permalink":"/tags/prometheus/","section":"Tags","summary":"","title":"Prometheus","type":"tags"},{"content":"","date":"20 5月 2026","externalUrl":null,"permalink":"/tags/slurm/","section":"Tags","summary":"","title":"Slurm","type":"tags"},{"content":"","date":"2026-05-19","externalUrl":null,"permalink":"/ja/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"2026-05-19","externalUrl":null,"permalink":"/ja/tags/docker/","section":"Tags","summary":"","title":"Docker","type":"tags"},{"content":"","date":"2026-05-19","externalUrl":null,"permalink":"/ja/tags/latex/","section":"Tags","summary":"","title":"LaTeX","type":"tags"},{"content":"","date":"2026-05-19","externalUrl":null,"permalink":"/ja/tags/latexit/","section":"Tags","summary":"","title":"LaTeXiT","type":"tags"},{"content":"","date":"2026-05-19","externalUrl":null,"permalink":"/ja/tags/macos/","section":"Tags","summary":"","title":"MacOS","type":"tags"},{"content":"","date":"2026-05-19","externalUrl":null,"permalink":"/ja/categories/notes/","section":"Categories","summary":"","title":"Notes","type":"categories"},{"content":"","date":"2026-05-19","externalUrl":null,"permalink":"/ja/notes/","section":"Notes","summary":"","title":"Notes","type":"notes"},{"content":"","date":"2026-05-19","externalUrl":null,"permalink":"/ja/","section":"Shota Ikari","summary":"","title":"Shota Ikari","type":"page"},{"content":"","date":"2026-05-19","externalUrl":null,"permalink":"/ja/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"LaTeXiT is a small macOS application that I find very convenient when I want to typeset a single equation and paste it into slides, notes, or figures. The annoying part is that LaTeXiT expects ordinary LaTeX-related commands such as pdflatex, ps2pdf, and gs to be available on the host machine.\nI wanted to keep my host environment light and use the same LaTeX environment that I already manage through Docker. This note describes the small wrapper-script setup I used to make LaTeXiT call LaTeX tools inside a Docker container.\nGoal # The goal is simple:\nkeep the TeX Live environment inside Docker, let LaTeXiT behave as if pdflatex, ps2pdf, and gs were installed locally, avoid root-owned output files, make temporary files created by LaTeXiT visible from inside the container. The key idea is to place wrapper scripts somewhere in my PATH, and then point LaTeXiT\u0026rsquo;s program paths to those scripts.\nWrapper scripts # I created three scripts under my local bin directory:\n~/bin/pdflatex_docker.sh ~/bin/gs_docker.sh ~/bin/ps2pdf_docker.sh Each script runs the corresponding command inside the same Docker image. In my setup, I adopted the image of lualatex-template-tex-ubuntu:latest.\nThe pdflatex wrapper looks like this:\n#!/bin/bash CWD=$(pwd) CACHE_DIR=\u0026#34;/tmp/texmf-cache\u0026#34; mkdir -p \u0026#34;$CACHE_DIR\u0026#34; docker run --rm \\ --user $(id -u):$(id -g) \\ -e TEXMFVAR=\u0026#34;$CACHE_DIR\u0026#34; \\ -v /tmp:/tmp \\ -v /var/folders:/var/folders \\ -v \u0026#34;$CWD\u0026#34;:\u0026#34;$CWD\u0026#34; \\ -w \u0026#34;$CWD\u0026#34; \\ lualatex-template-tex-ubuntu:latest \\ pdflatex \u0026#34;$@\u0026#34; The Ghostscript wrapper is almost the same:\n#!/bin/bash CWD=$(pwd) docker run --rm \\ --user $(id -u):$(id -g) \\ -v /tmp:/tmp \\ -v /var/folders:/var/folders \\ -v \u0026#34;$CWD\u0026#34;:\u0026#34;$CWD\u0026#34; \\ -w \u0026#34;$CWD\u0026#34; \\ lualatex-template-tex-ubuntu:latest \\ gs \u0026#34;$@\u0026#34; And the ps2pdf wrapper is:\n#!/bin/bash CWD=$(pwd) docker run --rm \\ --user $(id -u):$(id -g) \\ -v /tmp:/tmp \\ -v /var/folders:/var/folders \\ -v \u0026#34;$CWD\u0026#34;:\u0026#34;$CWD\u0026#34; \\ -w \u0026#34;$CWD\u0026#34; \\ lualatex-template-tex-ubuntu:latest \\ ps2pdf \u0026#34;$@\u0026#34; After creating these files, I made them executable and ensured that ~/bin was included in my shell PATH.\nchmod +x ~/bin/pdflatex_docker.sh chmod +x ~/bin/gs_docker.sh chmod +x ~/bin/ps2pdf_docker.sh For my shell environment, this means having something like the following in the shell configuration:\nexport PATH=\u0026#34;$HOME/bin:$PATH\u0026#34; Even so, I used absolute paths when configuring LaTeXiT itself, because GUI applications do not always inherit the same PATH as an interactive shell.\nWhy these options matter # There are a few details that turned out to be important.\nFirst, --user $(id -u):$(id -g) prevents Docker from creating root-owned output files. Without this, generated files can become annoying to clean up or overwrite from macOS.\nSecond, the current working directory is mounted into the container:\n-v \u0026#34;$CWD\u0026#34;:\u0026#34;$CWD\u0026#34; -w \u0026#34;$CWD\u0026#34; This makes relative paths behave naturally. LaTeXiT can create files in its temporary working directory, and the command inside Docker sees the same directory as its working directory.\nThird, I mounted both /tmp and /var/folders:\n-v /tmp:/tmp -v /var/folders:/var/folders On macOS, GUI applications often use temporary directories under /var/folders. If LaTeXiT asks pdflatex to compile a file in such a directory, the Docker container also needs to see it. Mounting /var/folders was the small but essential macOS-specific part of the setup.\nFinally, pdflatex_docker.sh sets TEXMFVAR to a writable cache directory under /tmp. This avoids cache-related permission issues inside the container.\nLaTeXiT configuration # In LaTeXiT, I opened the preferences and replaced the command paths with the wrapper scripts:\npdflatex -\u0026gt; /Users/ikarishota/bin/pdflatex_docker.sh ps2pdf -\u0026gt; /Users/ikarishota/bin/ps2pdf_docker.sh gs -\u0026gt; /Users/ikarishota/bin/gs_docker.sh LaTeXiT configured to call Docker wrapper scripts for pdflatex, Ghostscript, and ps2pdf. The exact UI labels depend on the LaTeXiT version, but the important point is that LaTeXiT should call the wrapper scripts instead of host-installed binaries.\nI also enabled \u0026ldquo;Use current user\u0026rsquo;s login shell\u0026rdquo; in LaTeXiT. In this setup, the program paths are absolute, so this is not the only thing making the wrappers discoverable, but it is still useful when the commands depend on shell-side environment variables.\nOnce this is configured, LaTeXiT still feels like a native macOS app. The only difference is that the actual LaTeX toolchain runs inside Docker.\nResult # As a quick check, I typeset a standard equation in LaTeXiT. From the application side, nothing special is visible: I write LaTeX source, press the typesetting button, and get the rendered equation back.\nA LaTeXiT equation rendered through the Docker-backed LaTeX toolchain. This was the main thing I wanted from the setup. The Docker layer stays hidden behind the wrapper scripts, while LaTeXiT remains convenient for quick equation snippets.\nA small trade-off # This setup is not the fastest possible one, because each LaTeXiT compilation starts a short-lived Docker container. For my use case, that overhead is acceptable: I usually typeset small equations, and I prefer reproducibility and a clean host environment over shaving off a little startup time.\nIf the startup cost becomes irritating, a natural next step would be to keep a long-running container alive and execute commands inside it. For now, the stateless docker run --rm approach is simple enough that I like it.\nConclusion # The useful pattern here is not specific to LaTeXiT. When a macOS application expects a command-line tool, a thin wrapper script can often bridge it to a Dockerized environment. In this case, three wrapper scripts were enough to make LaTeXiT use a Docker-managed LaTeX installation while keeping the host machine relatively clean.\nIf you also want to keep your local LaTeX installation minimal, this setup may be worth trying.\n","date":"2026-05-19","externalUrl":null,"permalink":"/ja/notes/latexit-docker/","section":"Notes","summary":"","title":"Using LaTeXiT with a Docker Environment","type":"notes"},{"content":"","externalUrl":null,"permalink":"/ja/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/ja/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":" 所属 # 東京大学大学院 情報理工学系研究科 システム情報学専攻 中村・高瀬研究室 修士課程 2年\n学歴 # 期間 所属 2025.04 - 現在 東京大学 大学院 情報理工学系研究科 システム情報学専攻 修士課程 2021.04 - 2025.03 京都大学 工学部 電気電子工学科 2018.04 - 2021.03 大阪府立 茨木高校 職歴 # 期間 所属 2025.05 - 現在 Preferred Networks, Inc. Research Engineer 2026.01 - 2026.02 Recruit Co., Ltd. Software Engineer Internship 2025.04 - 2026.01 東京大学 TA 2022.03 - 2024.08 DATAGRID Software Engineer 資格 # 取得年月 資格名 2024.09 統計検定準1級 ","externalUrl":null,"permalink":"/ja/profile/","section":"プロフィール","summary":"","title":"プロフィール","type":"profile"},{"content":" 研究関心 # 量子計算機アーキテクチャ 量子誤り訂正 機械学習 Preprints # Yuga Hirai, Shota Ikari, Yosuke Ueno, Yasunari Suzuki, \u0026ldquo;No More Hooks in the Surface Code: Distance-Preserving Syndrome Extraction for Arbitrary Layouts at Minimum Depth,\u0026rdquo; arXiv:2603.01628 [quant-ph], 2026. Yuga Hirai, Shota Ikari, Yosuke Ueno, Yasunari Suzuki, \u0026ldquo;A 2d x d x d Spacetime Volume Implementation of a Logical S Gate in the Surface Code,\u0026rdquo; arXiv:2604.13632 [quant-ph], 2026. Talks # 猪狩 翔太, 平井 優我, 上野 洋典, 鈴木 泰成, 山本 直樹, 中村 宏, 「表面符号上の Transversal CNOT ゲートを対象とした window decoder の検討」, 第203回HPC・第17回QS合同研究発表会, 北海道, 2026年3月. 口頭発表. 猪狩 翔太, 伊藤 向子, 「FPGAを用いたYOLOv5nのアクセラレーション - Hackathonを通じた実装報告 -」, リコンフィギャラブルシステム研究会 (RECONF), 2025年9月. 招待講演. Awards # Date Name 2025.06 Agile-X FPGA AI デザインハッカソン 第2位 Scholarships # Period Name 2023.04 - 2025.03 令和5年度 京都大学 CF プロジェクト奨学金 ","externalUrl":null,"permalink":"/ja/research/","section":"研究","summary":"","title":"研究","type":"research"}]