タグ別アーカイブ: Linux

CentOS 8のサポート期間の考え方は6や7とは異なります

CentOS 8.x (クローン元であるRHEL 8も含む)では CentOS 6 や 7 までとはいくつかサポート期間(サポート期限)の扱いが異なっています。

BaseOSリポジトリとAppStreamリポジトリ

CentOS 8 ではOSとしての機能を提供する「BaseOS」リポジトリと、開発言語やデータベースサーバー等を提供するアプリケーションストリームのリポジトリである「AppStream」リポジトリの2つのリポジトリで構成されます。また、パッケージ管理を行うdnf(これまでと同様にyumコマンドを実行した場合もdnfが呼ばれる)にはモジュールという仕組みが有り、モジュールの切り替えという概念が追加されています。

BaseOS リポジトリ:
CentOS 8 のOSとその周辺機能が提供されます。
サポート期限は2029年5月末まで。

About/Product – CentOS Wiki
https://wiki.centos.org/About/Product

OSとその周辺機能は10年間のサポートが提供されます。この期間はCentOS 7と同様です。

AppStream(アプリケーションストリーム)リポジトリ:
各種開発言語やRDBMS、サーバーアプリケーションやその他の各種ツール類等が提供されます。
サポート期限はアプリごとのストリームにより異なります。

Red Hat Enterprise Linux 8 Application Streams Life Cycle – Red Hat Customer Portal
https://access.redhat.com/support/policy/updates/rhel8-app-streams-life-cycle

主な内容とそれぞれのサポート期限は上記リンクを参照してください。RHELでの情報ですがクローンであるCentOSも同じ扱いになるかと思います。AppStreamでは例えばWebサーバーのApache、Nginx、ソフトウェア開発関連ではPHP、Ruby、Python、Perl、OpenJDK、データベースサーバーとしてはMySQL、MariaDB、PostgreSQL、Redisなどが提供されています。

アプリケーションによっては複数バージョンから選択して導入する事が出来るようになっており、どのバージョンを導入するかはモジュールの有効化・無効化で選択する事が可能です。モジュールはPHPであればCentOS 8.0 1905時点では7.2のみの提供でしたがCentOS 8.1 1911でPHP 7.3のモジュールが選択できるようになり、同様にNodeJSでは10に加え12が、Rubyでは2.5に加え2.6が選択出来るようになるなど、ある程度新しいバージョンをキャッチアップしていく事が可能なようです。

現在利用可能なモジュールは
dnf module list (yum module listでも可)
を実行する事で表示されます。また、
dnf module list –enabled
を実行する事で現在有効なモジュールのみが一覧表示されます。

なお、AppStreamで提供されているすべてがモジュールになっている訳ではなく、例えばgitコマンドなど複数バージョンから選択して導入するという要素が薄いようなものはモジュールの選択は有りません(上記のリンク先に掲載されていないアプリ・ツール類が多く存在します) (*1) 。

変化していくCentOSの立ち位置

つまりCentOS はCentOS 7までの

・サポート期間が開発言語やRDB、Webサーバー等含めディストリビューション全体で長大で、本家でサポート期間が終了していてるソフトウェアでもある程度のセキュリティフィックスが提供される。
・そのサポート期間を目的にする場合は化石のようなバージョンを使い続ける必要が有る(例えばCentOS 7ではPHPは5.4、Rubyは2.0.0が導入される)。それが困るので有れば別途リポジトリを追加するなりコンパイルするなりして導入する。

というディストリビューションからCentOS 8では

・OSとその周辺機能のサポート期間は10年確保しつつ、開発言語やRDBMS等の各種アプリケーションのサポート期間はそれよりも短い期間。
・各種アプリケーションは比較的新しいバージョンに能追従可能(追従していく必要が有る、とも言う)で、公式リポジトリのみでバージョンの切り替えができる。

というディストリビューションに変化します。

「化石バージョンでいいなら全てが長期間サポートされる一枚岩のLinuxディストリビューション」ではなくなったので、利用ソフトウェアの運用方針に注意しましょう。

Using AppStream :: CentOS Docs Site
https://docs.centos.org/en-US/8-docs/managing-userspace-components/assembly_using-appstream/

Managing versions of Application Stream content :: CentOS Docs Site
https://docs.centos.org/en-US/8-docs/managing-userspace-components/assembly_managing-versions-of-appstream-content/

※1: メール関連ではPostfixはBaseOSリポジトリで提供される一方でDovecotはAppStreamリポジトリ内に含まれています。何とも言えない基準。


WSL (Windows Susystem for Linux) を本格的に開発で使い始めた話

とある理由から WSL (Windows Susystem for Linux) を本格的に開発で使い始めました。その環境や手順、所感など。

前提: これまでの開発環境

  • PHP (Windows版)、メインで使うバージョンだけパスを通し、それ以外のバージョンは手打ちという方法で簡単に複数バージョン共存できます。WebサーバーもPHPのビルトインサーバを使います。
  • Composer(Windows版)、こちらもWindows版が有りあります。
  • MySQL (Windows版)、MySQL / MariaDB を使っている環境の開発用。唯一Linux向けと明確に異なる点としてDB名やテーブル名の大文字小文字を区別しませんが、小文字しか使わないので特に問題になりません。
  • PostgreSQL(Windows版)、PostgreSQLを使っている環境の開発用。特に何も困らず動きます。
  • Node.js、Windows版を利用。Node.js向けのアプリを書くのではなく各種ツールを利用するために導入。npmやwebpackなど特に問題なく動きます。
  • Redis(Windows版)、Windows向けのRedisは若干バージョンが古いものしか見つかりませんがまぁ普通に動きます。
  • Git for Windows、どちらかというとmingwを利用するための導入。実際のGitクライアントとしてはSource TreeのWindows版を利用しています。

前提: これまでのノウハウなど

Windows環境にちゃんと動くComposerを導入する

Windows環境のComposerを複数PHPバージョンで使い分ける

WindowsのコマンドプロンプトからOS標準のsshやtarやcurlコマンドを使う

上記を雑にまとめるとPHPの複数バージョン共存はWindowsでも簡単だし、ごく一部でLinux環境に依存しているComposerパッケージもGit Bashから実行すれば問題無いという話です。

発生した課題

この環境で長らく問題が無かったのですが、Symfony 4 + Flex の環境で開発するにあたって、/bin/console からのコマンドがコマンドプロンプトからは上手く動作しません。これは consoleがWin32なバイナリではなくshebang でPHPを実行しているからなので、ちょっと工夫すれば動くかと思われるのですが、せっかくLinuxに依存する物の実行環境としてgit bashを用意しているのでそれを使ってみます。

実際git bashで問題なく動くのですが、git bash(の利用しているmingw)の限界としてCtrl + Cでビルトインサーバーを止める事が出来ませんでした。どちらも制限アリで使えるのですが、この際せっかくなので本格的なLinux環境としてWSL (Windows Subsystem for Linux)を導入してみます。

WSLはかつてのバージョンではソケット通信が出来なかったりPostgreSQLなどの高度なツールが使う一部の機能に対応せず動作しなかったりデーモンとしてのプログラム起動が出来なかったりしましたが、2018年10月13日現在のWindows 10 リリース1803においては問題ない状態となっているようです。

導入方法

ググればいくらでも情報は出てくるので簡単に。ただしWSLリリース初期は今とは若干異なる手順でしたので古い情報にはお気を付けください。

  1. 「プログラムと機能」→「Windowsの機能の有効かと無効化」→「Windows Subsystem for Linux」を有効化。OS再起動を求められるので再起動します。

  2. Microsoft StoreでUbuntu 18.04 LTSをインストール。他のバージョンやUbuntu以外にもいくつかディストリビューションが選べます。
  3. スタートメニューからUbuntuを起動する。初回起動はインストールの続きが行われるので長めです。一般ユーザー名とsudo時に使うパスワードを求められますがどちらもWindowsのログインに使っているものと同じでにしました。
  4. フォント指定やデフォルトウィンドウサイズの変更はタイトルバー右クリック→「プロパティ」から。個人的にターミナル向けフォントとして長年使っているVLゴシックを指定。
  5. インストールしたままだと一部パッケージが最新でないのでaptコマンドで初回のパッケージ更新を行います。
    sudo apt update
    sudo apt upgrade
  6. あとはほぼ普通のUbuntu Linux環境ですのでaptコマンドなりなんなりで必要なツールチェーンを入れます。私はUbuntu公式のレポジトリからPHP 7.2を導入しました。Windows上のドライブは /mnt/ 配下にマウントされているので開発中リソースはそのままWSL上からも見えますのでどちらからも編集できます。

動作状況

Symfony 4 + Flex の /bin/console CLIなど特に問題なく動作します。/bin/console server:run によるビルトインサーバ起動も問題なく動き、Ctrl + C による終了も問題ありません。

今回PHPを実行する環境としてWSL上でPHPを動かしていますが、DBへの接続はlocalhost指定であろうとTCP/IP接続なので、これまで使っていたWindows版のMySQLやPostgreSQLに普通に接続できます。今はWSL上でもPostgreSQLなどが動きますが速度的にもとりあえずWindows版のまま使おうと思います。

また、ソースをWindows上で動くPHP Stormで編集する事も、それらをWindows版のSource TreeでGit管理する事も特に問題有りません。必要な部分だけをWSL上から実行する事が出来ます。

速度は気持ち程度遅いですが、PHPビルトインサーバを使っている分には特に困らないです。

所感

以前は辛い部分も多かったようですが、今の所思っていた以上に普通のLinux環境として使えます。普段からLinuxサーバーを触っている身としては独自の文化やしきたりを求められないのは使いやすいです。各種アプリパッケージの導入も apt コマンドなど「Linuxディストリビューションとして普通の方法」で行う事が出来ます。Virtual Machineのような環境ではなく、あくまでWindowsのまま必要なツールだけをWSL上から実行できるのも使い勝手が良いですね。

動作速度的にもWSL上でRDBを起動し巨大なテーブルを幾つも載せる、といったような使い方にはあまり向いていないと思われるので、RDBはWindows版を使ったまま「これまで以上にリッチかつナチュラルに使えるLinuxツールチェーン環境」として使うのが良いんじゃないかと思います。


WindowsのコマンドプロンプトからOS標準のsshやtarやcurlコマンドを使う

かつては色々な方法が有りましたが、Windows 10 (April 2018 Update以降) 現在においては特に追加で入れなくてもOS標準で以下のコマンドが使えるようになっています。

    • ssh (ssh-keygen等も含む)
    • sftp
    • scp
    • tar
    • curl

Windows 10にはLinuxのほぼフル機能が使えるWSL(Windows Subsystem for Linux)が有りますがそれを導入せずとも利用できます。唐突にLinux/Unixサーバーに接続してあれこれしたくなった時にも十分対応できそうな感じですね。

コマンドプロンプトのコードページ設定が932(ANSI/OEM 日本語 Shift-JIS)のままでもUTF-8なサーバーに接続してUTF-8なテキストファイルは普通に編集できるので普通に実用可能かと思います。

whereコマンドで探してみると C:\Windows\System32\OpenSSH\ssh.exe が存在している事が分かる。
※2行目に有るものはGitBashで導入されたsshコマンド。

Windows 10 RS4に追加された「curl」と「tar」コマンド
http://ascii.jp/elem/000/001/630/1630041/