最近は少しメモリ関連の記事を書いていましたが、この記事はそれとは直接関係なく、以下のサーバー運用系の記事の続きになります。
前回最後に、「VALUE SERVER→ConoHa VPS移行作業で漏れた部分」をやっていくということにしてました。まずはgit関連のアプリ追加などを行いたいので、今回はWebとデータベースとアプリを個別に起動/停止できるよう、docker-compose.ymlファイルを分離してみます。
最近は少しメモリ関連の記事を書いていましたが、この記事はそれとは直接関係なく、以下のサーバー運用系の記事の続きになります。
前回最後に、「VALUE SERVER→ConoHa VPS移行作業で漏れた部分」をやっていくということにしてました。まずはgit関連のアプリ追加などを行いたいので、今回はWebとデータベースとアプリを個別に起動/停止できるよう、docker-compose.ymlファイルを分離してみます。
前回は仮想メモリを調査し、使用されて始めて実メモリを確保することが明確になりました。そして純粋にメモリという意味では、psコマンドのVSZ(やSZ)はさして有用ではなく、RSSと出来ればswapが欲しいな…でもpsコマンドではswapは出せず、proc filesystemの力を借りていました。原始的ですね。
それならば…と今回はリアルタイムpsとも言うべきtopコマンドの出番です。bsdの呪いを解いたのも束の間、実はPOSIX標準の呪いにかかっていたpsコマンドを救うために、標準に縛られないニューヒーローtopコマンドにスポットライトを当てます。
前回はpsコマンドのSZについて調べました。
結局仮想メモリ含む全メモリという説明をしたのですが…じゃあSZが1GB使ってて、RSSが100MBだったら、残り900MBがスワップなのかというとそういうわけでもありません。スワップなんて全くされてない…なんてこともあります。今回はこのカラクリを説明しようと思います。
psコマンドは誰もがお世話になる便利コマンド。派生コマンドも多いし、リアルタイムに見たいからtop使ったり、その派生使ったり、アウトローな輩が/procを直に見るからpsコマンドいらんとか言ってたり、sar経由でグラフにならないと見ない御仁もいるかもしれないけど、とにかくその誰もが最初に学ぶ基本コマンドがpsなのだ。
今日はそのpsコマンドの出力、SZについての疑問に迫る。うん、誰も興味ないのは知ってる。
前回はVALUE SERVERからConoHa VPSへのこのサイトのWordPress移行方法を記事にしました。
このサイトのWordPressやMySQL、nginxなどが動いてるDockerコンテナが乗っているのは母艦であるUbuntuです。
今回はUbuntuのパッケージ自動更新について話します。
そろそろLuxeritasからの移行を考えているからです。公開した以上どこかでメンテナンスをやめるなら、引き継ぎ可能な状態にしようという意味合いです。
改変パッチの配布が面倒だからです。配布物に含まれるコードはGPLなのにminifyしたソースしか含んでいなかったり、各ファイルのライセンスが明確ではありません。通常GPLならminifyする前のソースを要求し、そのソースは再配布も堂々とできるのですが、これだけしっかり配布している中それらソースをどこにも置いていません。サイトを読む限りGPLについても独自の見解をお持ちのようで、弁護士を頼んで云々とあり、正直あんまり関わりたくありません。
本来であればパッチ配布などという形態にしなくても、gitリポジトリごとどこかに置いてもらえば、こちらもフォークして修正して公開できるわけです。あとはプルリクエスト出したりと健全な活動で取り込まれれば私の作業はなくなるし、リジェクトされても他の人がフォークしたものに取り込むのは容易なわけで、いずれにしても私の作業はかなり楽になります。極めつけが先のminifyソースなのですが…これは実際の作業で実感してもらうべきですね。
前回はConoHa VPSでWordPressを立ち上げました。
今回はこのWord PressにVALUE SERVERで取得したデータを移行します。
前回はdockerのnginxを使ってhttpsで公開できるようにしました。
今回はdockerを使ってWordPressをhttpsで公開できるようにしてみます。
前回はLet’s EncryptでSSL証明書を取得しました。
今回はいよいよhttpsでWebサーバーを立ててみます。
前回はdockerを使ったプロキシサーバーを立ててみました。
今回はいよいよhttpsに必要なSSL証明書の取得に取り組みます。