現代ITインフラの王道をゆくLinuxパッケージ管理の基本構成 | 外道父の匠
RedHat系におけるRPMパッケージを扱うYUM、Debian系におけるDEBパッケージを扱うAPT、これらはサーバー管理において重要なわけですが、絶妙な度合いで、おざなりに扱ってもわりとなんとか運用出来てしまう感があります。そのため今一度、こんな感じが今風のスタンダードじゃないっすかね（ｷﾘｯ という構成を説明してみます。 ぶっちゃけ、たいしたことないネタの集合体なので、タイトルに下駄を履かせました。 そもそもパッケージは必要なのか 言うまでもなく必須です。理由は、インストール物のファイル管理が容易になるのと、インストール時間を短縮できるからです。既存のパッケージでconfigureオプションが物足りない時や、RPMパッケージが存在しない場合は作成することになります。 最近はプロビジョニング・ツールによって全て自動化できるので、超簡素なコンパイルのものはレシピに落とし込んで終わりにした
ビッグデータツールチェインのセキュリティはビッグリスク、あるいは、誰もHadoopをスクラッチからビルドする方法を知らない件について
ビッグデータツールチェインのセキュリティはビッグリスク、あるいは、誰もHadoopをスクラッチからビルドする方法を知らない件について The sad state of sysadmin in the age of containers コンテナー時代のシステム管理者の惨状 システム管理は惨劇に見舞われている。現状は悲惨だ。 筆者は昔気質のシステム管理者に不満はない。システムの稼働を維持し、アップデートし、アップグレードする方法を知っている者達だ。 この憤りは、コンテナーと構築済みVMと、それらがもたらす、「信頼」や「アップグレード」の欠如による悲惨な惨劇に対するものだ。 例えば、Hadoopを見てみろ。誰もHadoopをスクラッチからビルドする方法を知っているようには見えないぞ。依存性とバージョンとビルドツールが悲惨なほどに絡まりあっている。 この手のイケてるツールの中で、古典的なmake
Docker を用いた rpm / deb パッケージ作成の継続的インテグレーション - ゆううきブログ
サーバ管理ツールのエージェント みたいなソフトウェアをインストールしやすくするために、rpm / deb パッケージを作りたい。 しかし、rpm / deb パッケージ化するためには、それぞれ CentOS(RedHat)、Debian(Ubuntu) 環境でパッケージ化することになる。 社内ではこれまでパッケージ化の専用ホストがいて、そこで spec ファイルや init スクリプトを置いて rpmbuild コマンドとか debuild コマンドを叩いてパッケージを作成していた。 さらに、アプリケーションエンジニアからインフラエンジニアに依頼するという形をとっていた。 この方法の問題点として、以下の3つがある。 spec ファイルや init スクリプトなどをプロジェクトの Git リポジトリで管理しづらい。つまり、レビューとかがやりにくい。 リリースフローを自動化しづらい。具体的には
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
