【研修資料公開】低レイヤを学ぶ、Linuxカーネルとコンテナの仕組みの研修 | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
こんにちは、羽山です。 今回はラクーンホールディングスの座学研修で私が講師を担当する 3年次 Linux && Docker研修 をご紹介します。当社は教育制度に力をいれており、入社直後に5~6ヶ月間の研修があります。そしてさらに n年次研修 という枠組みで2年次、3年次、4年次と定期的に研修を実施して、経験を積んだ各ステージに必要な知識・スキルを補完しています。 3年次 Linux && Docker研修は入社から3年目の1~2月頃（4年目目前）に実施していて、エンジニアとしての実力も付いてきた段階で受けることになります。 4年目目前ともなれば Linux や Docker を普段から開発に利用していて基本操作には困っていないはずです。 一方で Linuxカーネルの役割を聞かれたら返答に窮したり、コンテナとはプロセスと言葉では知っていても実はよく分からなかったり、そういうあたりが本研修の
![【研修資料公開】低レイヤを学ぶ、Linuxカーネルとコンテナの仕組みの研修 | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/e9a13379b158995ad75b38176e534851111a7715/height=288;version=1;width=512/https%3A%2F%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2025%2F01%2Flinux-docker-00.png)
シェルのバックグラウンド実行って後だしできるって知ってました？ - Qiita
この前までの私のちょっと時間のかかるバッチ実行の日常 「よっしゃー、今日はバッチ処理やるで！」と気合い入れて、タタタタッターン（bash xxxx.sh + Enter）。 おっと、またやらかしたわ。コマンドの末尾に&つけんの忘れたら、プロセスがフォアグラウンドで動いてまうねん。 これやと、ターミナルがこのタスクに独り占めされてまうわ。 この状況をどうにかするには、Ctrl+Cでプロセスを止めてからやり直すか、それとも別のターミナルウィンドウを開くしかないねん。めっちゃ面倒くさいなあ。 今後の私のちょっと時間のかかるバッチ実行の日常 「さて、本日はバッチ処理の実施日でございますね」と心に留めました。 タッタタタッターン。 あら、不覚にも再び&を添え忘れてしまい、結果としてフォアグラウンドでの実行を余儀なくされました。 しかし、ご心配なく。 まずは、Ctrl+Zを駆使してプロセスを一時停止い
1Password の ssh-agent 機能を WSL/WSL2 でも利用する(2023/12版) - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 1Password のバージョン8では、SSH Key の管理機能(接続先エントリごとに public key, fingerprint, 秘密鍵を管理)、および、ssh-agent 機能が導入されました。 これにより、例えば GitHub に SSH 接続する際に、コマンドラインで ssh-keygen した後、ssh-add で生成された秘密鍵を追加、public key は GitHub のウェブ画面から追加といった一連の作業をしなくても、1Password がいい感じに管理してくれます。 この素晴らしい機能、WSL2上
第55回 コンテナと仮想マシンのマネージャ"Incus" | gihyo.jp
この連載は、「LXCで学ぶコンテナ入門」というタイトルです。序盤を除くと、LXC自身を紹介するというよりは、Linuxカーネルに実装されているコンテナ関連の機能を紹介をすることが多く、カーネルの機能を紹介する際に、実行例でLXCを使ってきました。その後、LXCを開発しているLinuxContainersプロジェクトからは、コンテナマネージャとしてLXDの開発がスタートし、この連載でもLXDを使ってカーネルの機能を説明することがありました。 LXDは、コンテナと仮想マシンの両方を管理できるマネージャソフトウェアです。LXCもLXDも、OS環境を起動させるシステムコンテナを扱うことを主眼に開発されています。 gihyo.jpでは、LXDについては本連載ではなく、Ubuntu Weekly Recipeで柴田充也さんが頻繁に取り上げており、基本的な操作から応用まで幅広い話題が紹介されています。
POSIXシェルスクリプトではwhichではなくcommand -vを使うべき理由（＋シェルスクリプト版which） - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 重要 2022-01-30 追記 この記事で解説していた警告の出力は 2022-01-21 に取り消されました（参照 Revert deprecation of which）。そのため Debian which が GNU which に変わることは（少なくとも近い未来では）ないと思います。しかしながら which を使うよりは POSIX で規定されている command と type を使う方を推奨します。 はじめに which コマンドはシステムにインストールされてるとは限りません。実際に最小構成でインストールされてない環境として
第796回 LXDとIncus、今後どちらをUbuntuユーザーは使うべきか？ | gihyo.jp
Ubuntu Weekly Recipe 第796回LXDとIncus、今後どちらをUbuntuユーザーは使うべきか？ 本連載でも何度か紹介しているコンテナ・仮想マシンの管理システムである「LXD」がCanonicalの管理になった結果、コミュニティ版の「Incus」が登場しました。詳しい経緯は「LXCで学ぶコンテナ入門」の第55回「コンテナと仮想マシンのマネージャ"Incus"」に記述されています。今回は少し趣向を変えて、「UbuntuユーザーはLXDとIncusのどちらを使うべきか」という観点から、Incusを紹介します。 UbuntuとLXDとIncus 冒頭でも説明したように、LXDのコミュニティ版フォークとしてIncusが登場しました[1]。 フォークに至った詳細な流れは「LXCで学ぶコンテナ入門」が参考になりますが、かんたんに説明すると次のような時系列になります。 Lin
お気に入りのコマンドラインツールを淡々と紹介する
めちゃくちゃ良い記事でした。 「OSS は使っていることを公言するだけでも貢献になる」と songmu さんが言っていたので、私も貢献したいと思います。 僕も貢献したいのでよく使うコマンドラインツールを紹介していきます。 特定のプログラミング言語等に依存するツールは省いています。 actionlint - GitHub Actions の Workflow ファイルの静的検査 GitHub Actions の Workflow ファイルの静的検査ツールです。 かなり精度が高く、色々な設定ミスを検知してくれます。 エラーメッセージも見やすくて助かります。 aicommits - コミットメッセージを自動生成 変更内容を元に自動でコミットメッセージを AI が生成してくれるツールです。 コミットをする前にちゃんと確認してくれるのも安心感があって良いです。 cLive - ターミナル操作を自動化
『systemdの思想と機能 ―Linuxを支えるシステム管理のためのソフトウェアスイート』でsystemdの機能を再確認する - Magnolia Tech
systemdの思想と機能 Linuxを支えるシステム管理のためのソフトウェアスイート Software Design plus 作者:森若 和雄技術評論社Amazon いつの間にかどのLinuxディストリビューションでも標準で使われるようになったsystemd。なんとなくsystemctlを叩いてサービスを立ち上げていたけど、いまいち「なんで必要なの？」とか、「いろいろ機能があるっぽいけど、何ができるの？」といったことをちゃんと勉強しないままここまで来てしまったので、この本でおさらい。 単なる機能紹介ではなく、「なぜsystemdはこんな広範囲な機能を扱うのか？」という機能が作られた背景から説明されているところがいいですね。 この本を読むまでcore dumpまで管理されるようになったことを知りませんでした。 本書を読めば、systemdはサービスが動く環境を用意するために必要な機能を備
良いシェルスクリプトのためのkillとtrapの基本 ～ シグナル番号は使わない、シグナル名を使う - Qiita
はじめに kill コマンドと trap コマンドはシェルでシグナルの送信と受信を行うためのコマンドです。このコマンドは意外と適切ではない使われ方をよく見かけます。この記事では kill と trap の基礎知識を解説します。 関連記事: こちらに trap を利用した終了処理のコードを書きました。 trapを使ったシェルスクリプトの終了処理のテンプレ（POSIX準拠） POSIX準拠のkillコマンドの構文 POSIX で標準化されている kill コマンドの使い方は次のとおりです。POSIX で標準化されているというのは移植性が高い書き方ということを意味しています。シグナル名の指定には -s オプションが必要です。そして signal_name であって signal_number でないことに注意してください。POSIX シェルの世界にシグナル番号という概念はありません。シグナル番号
【永久保存版】シェルスクリプト完全攻略ガイド - Qiita
シェルスクリプトの世界へようこそ！ シェルスクリプトって何？ シェルスクリプトは普段 Bash などのシェルで実行しているコマンドを並べて、まとめて実行できるようにしたものです。ファイルのバックアップ、ログファイルの解析、システムのセットアップなど、ターミナルで行っていた一連の作業をまとめてシェルスクリプトに記述することで、シェルスクリプトを実行するだけで自動的に一連の作業を終わらせることができるようになります。また、シェルスクリプトはファイルに保存することになるため、再利用するのも簡単になります。 シェルスクリプトで使うコマンドの多くは UNIX コマンドになると思います。そのため、シェルスクリプトを書く際は UNIX コマンドについてある程度の知識があることが前提となってきます。以下の記事などを参考に UNIX コマンドについても学んでおくことをオススメします。 シェルスクリプトはいつ
第54回 Linuxカーネルのコンテナ機能 ―cgroup v2から使うCPUの帯域幅制限（2） | gihyo.jp
前回は、CPUコントローラでの帯域幅制限がどのように行われるのかについて簡単に説明しました。 前回の最後に、説明のために挙げた例がかなり理想的な状況であると書きました。今回は、帯域幅制限の機能を詳しく見ていくために、前回よりはもう少し複雑な状況について説明していきましょう。 未使用クォータの返却 前回説明で示した例では、CPUは割り当てられたスライスをすべて使いきっていました。しかし、複数のCPUがある環境で、タスクが終了したり、I/O待ちなどにより、クォータが割り当たったCPUで実行可能なタスクがなくなった場合はどうなるでしょう? 図1 割り当てられたスライスが使われない場合 図1のように、クォータプールに10msクォータが残っているとします。 ①でCPU1でCPUを使用するタスクから要求がありスライスが転送され、クォータの残りが5msとなりました ②で再度CPU1でCPUを使用するタス
はじめに - Writing an OS in 1,000 Lines
本書では、小さなOSをゼロから少しずつ作っていきます。 OSと聞くと腰が引けるかもしれませんが、OS (特にカーネル) の基本機能は案外単純です。巨大なオープンソースソフトウェアとしてよく挙げられるLinuxでさえ、バージョン0.01はたった8413行でした。様々な要求に応えるために次第に肥大化していっただけで、当初は大変素朴な実装になっていました。 本書では素朴なコンテキストスイッチ、ページング、ユーザーモード、コマンドラインシェル、ディスクデバイスドライバ、ファイルの読み書きをC言語で実装します。これだけ様々な機能が詰め込まれているのに、コードは合計でたった1000行未満です。 「1000行なら1日でできそう」と思うかもしれませんが、初学者には少なくとも3日はかかるでしょう。OS自作のハマりポイントは「デバッグ」です。アプリケーション開発とは違うデバッグ手法・能力を習得する必要がありま
Linux システムコール 徹底入門
Linux システムコールについて調べたことをまとめる。システムコールの仕組みを理解すると、 OS とアプリケーションがどのように連携して動いているのかを理解できるようになります。 システムコールは CPU に依存する処理が多いため、 x86_64 に絞ります。 検証環境]# cat /etc/redhat-release CentOS Linux release 8.0.1905 (Core) ]# uname -a Linux localhost.localdomain 4.18.0-80.11.2.el8_0.x86_64 #1 SMP Tue Sep 24 11:32:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux ]# cat /proc/cpuinfo | head processor : 0 vendor_id : GenuineInte
TechFeed Experts Night#19 「トラブルシューティングから Linux カーネルに潜り込む」の発表をしました - Pepabo Tech Portal
セキュリティ対策室の 伊藤洋也 ( @hiboma ) です 5/24(水) に 株式会社テックフィード様 主催の オンラインイベントの TechFeed Experts Night#19 〜 達人に聞く、Linuxカーネルコードの歩き方 に登壇しました。 次のような趣旨で開催されたイベントになります。 今回のTechFeed Experts Nightは「達人に聞く、Linuxカーネルコードの歩き方」がテーマです。 Linuxカーネルコードのエキスパートたちが、最前線のトレンドからマニアックな技術情報を30分間のセッションに凝縮！ それらをネタに、エキスパートたちが語り合うアフタートークもあります！ 今回このイベントで 「トラブルシューティングから Linux カーネルに潜り込む」の発表をしました。 トラブルシューティングから Linux カーネルに潜り込む 発表のスライドはこちらです。
【Linuxカーネルを読む】ChatGPTで爆速コードリーディング - Qiita
はじめに OpenAIによって開発されたChatGPTが話題になっています。特に、2023年3月14日に公開された最新モデルであるGPT-4は、これまで私達がAIに持っていた認識を根底から覆したのではないでしょうか？ 私は、「普通に人間とやりとりしているのと変わらんやん…」と率直に驚きました。 エンジニアの業務の中でも、自動コーディング支援、技術的課題の壁打ち相手、ドキュメント自動生成、学習支援等さまざまな用途に活用する可能性を皆さん検証している段階です。私もその波に乗っている真っ最中です。 そこで今回は、ソースコードリーディングをChatGPTをメンターにしたら爆速にできるのではないか？という仮説を検証してみました。 そしてどうせやるなら、ソースコードリーディングのハードルの高さナンバーワン（個人調べ）の「Linuxカーネル」を題材にしてみました。 なお、使用したモデルはGPT-4です。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Linuxカーネルのコンテナ技術を解説する人気シリーズ『Linux Container Book』第3弾が発売／『Linux Container Book 3』は特殊な機能やセキュリティ面における興味深い点を深掘り【Book Watch/ニュース】
Linuxコンテナの仕組み / eBPF & Container Study in Fukuoka
パイプに関係するさまざまなバッファ、ちゃんと意識していますか？ - Qiita
device mapperによるディスクI/O障害のエミュレーション
【Ubuntu日和】 【第36回】SSH使うなら、これだけは覚えておきたい話
