概要 シンプルでクロスプラットフォーム、しかも構成しやすいVPNソフトウェアのWireGuardでVPN環境を作ります。WireGuardの設定ファイルはWg Gen Webを使ってWeb UIで管理します。設定ファイルはsystemdで監視し、WireGuardを自動で再起動、更新を反映します。ネットワーク設定は環境によって異なるため、環境に合わせて調整してください。 以下では、Ubuntu 20.04 LTSがインストールされたサーバにDockerとDocker Composeが利用できる環境が構築されていることを前提として進めていきます。 1. WireGuard環境の構築 WireGuard自体はaptで瞬時に入ります。そのままだと設定ファイルは手動で作成になりますが、それほど難しい作業ではないので、この時点で動作確認を行います。 sudo apt update sudo apt
by Adam Harvey Linuxを利用していると「シェル」や「grep」「プロセス」といった言葉を目にします。エンジニアのCarl Riis氏はそんなLinuxの基礎用語の意味や仕組みをさまざまなウェブサイトから学習し、「10のミニプロジェクト」を作成することでスキルを向上させたとして、その詳細を公開しています。 Getting better at Linux with 10 mini-projects - carltheperson https://carltheperson.com/posts/10-things-linux GitHub - carltheperson/10-things-linux: Getting better at Linux with 10 mini-projects. https://github.com/carltheperson/10-thing
はじめに この記事はDocker Advent Calendar 2017の13日目の記事です。 コンテナ運用はk8sがデファクトにほぼなったような感じはしますが、オンプレのようなマネージドなk8sが無い環境で、コンテナ化を進めるにあたり、いきなりk8sクラスタを作るというのは敷居が高いです。 そこで、少しづつコンテナ化を始める繋ぎとしてdocker-composeとsystemdを使ってカジュアルにdocker運用してみたので、その際のTipsについて記載します。 ちなみにdocker-composeなので当然サーバ間をまたいだオーケストレーションの層は考えず、単に既存サーバのプロセスをコンテナ化して運用することで、まずはサービスの移植性を高めることを目的としています。 docker-composeだけで運用する際の問題点 サーバ単体で複数のコンテナを連携させるにはdocker-comp
systemdではユニット(Unit)という単位でサービスやソケット、あるいは他のユニットをまとめるターゲットなどを管理しています。ユニット設定ファイルはプレーンテキストで書かれていて、これをsystemdが解釈してサービスやシステムの起動・停止を管理しています。 ところで、サービス同士やサービスとその関連するソケットの間では、「あるサービスは別のサービスが先に起動していないと使えない」「このサービスはあるソケットを必要としており、これよりあとに起動する必要がある」など、アクティベート順序(起動順序)や依存関係があります[1]。これらのアクティベート順序や依存関係もユニット設定ファイルに記載されていて、systemdが解釈し、適切に実行していきます。 今回は、このアクティベート順序や依存関係について、systemdのユニットの設定ファイルで使われる基本的なディレクティブとその設定を調
◆ Live配信スケジュール ◆ サイオステクノロジーでは、Microsoft MVPの武井による「わかりみの深いシリーズ」など、定期的なLive配信を行っています。 ⇒ 詳細スケジュールはこちらから ⇒ 見逃してしまった方はYoutubeチャンネルをご覧ください 【6/19開催】Kong Community Japan Meetup #4 本イベントでは、Kong Inc. のVP of ProductであるReza Shafii氏もプレゼンターとして参加。当社からはアーキテクト マネージャーの槌野の登壇が決定!参加無料です!! https://column.api-ecosystem.sios.jp/connect/kong/1081/ 【6/21開催】開発者目線でのSBOMとの向き合い方 SBOMの導入から開発者がSBOMの作成・管理を自動で行っていくための方法(デモ)を紹介します。
B! 82 0 0 0 RHEL 7系のCentOS 7などではそれまでRHEL 6系で使われていたSystem V系のinitから Systemdを用いたデーモン管理がベースになるようになりました。 CentOS 7でデーモンを自作したいものがあって作ったので 基本的な作り方についてまとめておきたいと思います。 Systemd (systemctl) デーモン本体作成 最小限の設定 サービスファイル rsyslogの設定ファイル logrotate インストール/アンインストールスクリプト 動作チェック まとめ Systemd (systemctl) initのときには/etc/init.d/の中にデーモン名の(通常)シェルスクリプトが入っていて、 このスクリプトがstartとかstopとかの引数を受ける様に作られ、 直接 # /etc/init.d/httpd start とかするか、
はじめに こんにちは、技術顧問の武内です。 本記事はサイボウズの次期インフラ開発チーム(Necoチーム)が遭遇した、CoreOS Container Linux (以降 CoreOS)においてリアルタイムプロセスを実行できないという問題について、次のようなことを記載したものです。 どういう問題なのか どのように根本原因を突き止めたのか 今後どのように対処するのか 問題要旨 本来なら成功するはずのroot権限におけるリアルタイムプロセスの実行が失敗する 根本原因 CoreOSではカーネルのリアルタイムグループスケジューリングという機能が有効になっている 同機能が有効な場合、cpu cgroup配下のプロセスはデフォルトではリアルタイムプロセスを実行できない systemd環境下で生成されたプロセスは何らかのcpu cgroupに所属させられる 対処方法 リアルタイムプロセスが属するcpu c
2018/06/07〜2018/06/08 あたりにtwitterでつぶやいたsystemdのうれしいシーンまとめ Package管理と相性がよい sysvinitのスクリプトちょっといじってulimit文足したあとにパッケージupdateしたら消えたりしたことがある人はsystemdならその不幸はもう起きない systemdは設定ファイルが /usr, /etc, /run くらいにバラけて配置されるのでパッケージが提供するのをカスタマイズで変更するのは簡単にできるしパッケージシステムの更新などと相性もいい。 バラバラだと作業が煩雑になりがちなので関連コマンドが充実 パッケージのデフォルト、/etc/での設定、/run/の自動生成された設定などをまとめてunitを表示してくれる systemctl cat unitをカスタマイズするときに適切なファイルを編集してくれる systemctl
ほとんどサービス動いてないサーバが急にメモリ使用率の警告出したので調べて見たら、1日に30MBくらい、1ヵ月で1GBくらいジワジワとSystemdがメモリリークしていたという話です。 事象 Systemdが異常にメモリを使っている。 $ ps aux | head USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.2 60.9 2327496 2207392 ? Ss 1月15 191:31 /usr/lib/systemd/systemd --switched-root --system --deserialize 21 root 2 0.0 0.0 0 0 ? S 1月15 0:00 [kthreadd] ... 何も動いていないのに2GBも何に使っているの?となった。 原因 結論から言うと、こちらのバグが原
cgrps v0.5.0 から cgrps ps コマンドは削除しました cgroup / cgroups 問題について下記に追記しました。それに伴いタイトルと文章も修正しました。 以前のエントリで書いたようにcgroupの状況を確認するコマンドはあります。 k1low.hatenablog.com ごく普通のcgroupsの使い方であれば上記エントリにある systemd-cgtop systemd-cgls や lscgroup などで十分です。 しかし、 たまたまなのですが 私が関わっているプロダクト ではコンテナをフル活用しているためcgroupが大量に作成されることがあり、systemd-cgtop などではなかなか厳しいことになってきていました。 また、同じcgroup階層のサブシステムの状況は「同じグループとして」確認したいという気持ちもありました。 cgrps というわけで
昨年末に Go言語で書いた Web アプリケーションの習作をサービス化して公開するところまでやってみた - えいのうにっき で公開したサービス・Yukizuri のデーモン化手段を、今日、supervisor から systemd に変更した。理由は単純で、会社の同僚(先輩)と「なんで supervisor 使ったの?」「今なら systemd がいいんじゃない?」といったような会話があったため(別に咎められたわけではない)。 今まで supervisor で以下のような指定をして動かしていたものを、 ; for yukizuri [program:yukizuri] command=/var/www/yukizuri/app/yukizuri.bin -addr=":8080" -logging=true autostart = true startsecs = 1 user = roo
Amazon Linux 向けに書いた Ansible Playbook を Amazon Linux 2 に対応させようと思ったのですが、facts を見ても区別できる要素がありません。必要なところだけ抜き出すとこんな感じです。 # Amazon Linux "ansible_distribution": "Amazon", "ansible_distribution_major_version": "NA", "ansible_distribution_release": "NA", "ansible_distribution_version": "2017.09", # Amazon Linux 2 "ansible_distribution": "Amazon", "ansible_distribution_major_version": "NA", "ansible_distri
Issue We have init scripts for versions of Red Hat Enterprise Linux 6 and earlier that we want to port to systemd unit files so that they will work on Red Hat Enterprise Linux 7 and newer. How do I convert init scripts to systemd unit files? I want to change my custom init script to be compatible with systemd Environment Red Hat Enterprise Linux 7 Red Hat Enterprise Linux 8 Red Hat Enterprise Linu
レナートがsystemdの構想について語ったブログエントリーの翻訳。 原文はこちら: Rethinking PID 1 投稿は2010年4月30日とかなり古いものではあるが、この時点で現在に至るまでのsystemdの設計思想がしっかり示されており、いまもなお色あせていないと思う。 レナートからブログエントリーの翻訳の許可を取り付けたので、せっかくだから一番最初に訳すのはこの記事にしたい。 一気に訳すだけの気力と時間はないので、何回かに分けて訳す。 記事を分割すると検索性が落ちるので、この記事に加筆修正していく。 最初からきちんと訳せるという気はしておらず、誤字・脱字・誤訳がたぶんいっぱいある。 なので、見つけた方はご指摘ください。徐々にいいものにしていきたい。 *1 PID 1 を考え直す 十分な関わりがあったり、行間を読むのが得意であったりすれば、このブログ投稿が何に関することかはもう察
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く