[過去ログ] Arch Linux 15 (1002レス)
上下前次1-新
このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
608(2): 2020/11/27(金)19:44 ID:PegbniXW(1) AAS
>>539
うちも本番で使っているけど、
協力会社からチャレンジャーと言われたorz
安定してると思うのだけれどな…
609: 2020/11/27(金)20:11 ID:Vtk2GQLq(1) AAS
>>539
本番環境はちゃんと仮想化してバックアップしとけ。
>>608
そりゃそうだろ。
運用に大事なのは「設定・操作を再現できる」「イジった時/所だけ変わる」「元に戻せる」だからな。
ローリングリリースとか狂気の極み。
610: 2020/11/27(金)20:28 ID:o+rZFCOx(1) AAS
全部コンテナ化すればええんや!
611: 2020/11/27(金)20:43 ID:UxR5B9Rs(1) AAS
macbook airでarch動かないかな
612: 2020/11/28(土)01:14 ID:wRJx9xsV(1) AAS
archlinuxarchive活用すれば特定の時間におけるバージョン固定はできそう
613(1): 2020/11/28(土)02:01 ID:WSE99thr(1/2) AAS
>>608
うちはarchで開発環境にして、本番はubuntuの上にDocker環境でarchのイメージ使ってる。archでサーバーにするのが楽だと思うけど、サバ缶が嫌がる。
614(1): 2020/11/28(土)02:09 ID:166GwNQu(1) AAS
何度も言われているが
自分で構築したArchの管理は楽だが
他人が構築したArchの引き継ぎは地獄だから向いてない
615: 2020/11/28(土)02:15 ID:WSE99thr(2/2) AAS
>>614
そのとおりかもしれないけど、archで開発してるほうがサバ缶よりドキュメント残してるんだぜ。
どんなディストリのサバでもサービスの立て方が明確じゃないサーバーの管理はクソだよ。
向いてる向いてないはサービスによるんだよ。
616: 2020/11/28(土)07:03 ID:0GnVPzXa(1) AAS
ドキュメント不足のCentOSサーバーと
ドキュメント不足のArchサーバーでは深刻度が段違い。
自分でArchサーバーを構築したのではなく
他人が構築したArchサーバーを引き継いだ経験のある人だけが
Archサーバーを賞賛していい。
617: 2020/11/28(土)10:25 ID:YxP4KbOs(1) AAS
パッケージマネージャを使う限りはそれほど変わりないと思うのだが他の OS と
Arch って package Manager 使った時のソフトウェアのバージョン固定てできるの?
618: 2020/11/29(日)07:36 ID:GZGgUZrw(1/3) AAS
パッケージ指定して更新しないようにできる
619: 2020/11/29(日)07:40 ID:GZGgUZrw(2/3) AAS
クソがクソ比べするのはクソ過ぎて、そんな仕事したことない。
アマチュアの仕事ならやめたほうがいい
620: 2020/11/29(日)07:43 ID:GZGgUZrw(3/3) AAS
>>613の要件のサーバーならarchのほうが圧倒的に楽。Docker動かすだけなんだからローリングリリースの方がアップデートせずに使えるから。
621: 2020/11/29(日)09:50 ID:Yh8khkeI(1) AAS
自分で構築から管理まで行うなら楽という認識は共通でしょう。
他人が構築したArchを引き継ぐ場合の話が論点。
622: 2020/11/29(日)17:46 ID:TN7DRCH8(1) AAS
実機でarch入れてるのはうちの社ではCI用サーバーしかない
コンテナやVMだとたくさんarch使ってる
623: 2020/11/29(日)23:04 ID:7RRa7tfF(1) AAS
なんでRHEL使わないの…?
予算がつかない…?
624: 2020/11/30(月)00:50 ID:8w5EZNmq(1/3) AAS
archの指針通りシンプルに使い続けていれば引き継ぎも楽だよ。無能がサバ缶やる前提で話すからややこしくなる。
pacmanでDockerを入れるか、aptでDockerを入れるかの違いだろ。
625(1): 2020/11/30(月)01:01 ID:ZnAMLkM9(1) AAS
シンプルというのが
パッケージのバージョンを一切固定しないという意味ならそうなんだが
それはArchが楽というよりも
バージョンを上げても問題が発生しない楽なシステムをArch上で動かしてるというだけ。
626: 2020/11/30(月)02:25 ID:8w5EZNmq(2/3) AAS
>>625
認識が同じで安心したね、それを楽と言うか、大変と言うかはケースによって違うんだ。出向先の会社に建てるような小さいサーバーのケースではarchのほうが向いてる。
つまりケースによって違うってこと。
開発側のアプリケーションをそのまま使えないサーバーの運用には向いてない。
開発とサーバー運用を切り分けられない現場だとarchサーバーは難しい。
627(2): 2020/11/30(月)04:02 ID:WYdCiCNg(1) AAS
それって要はトラブル発生しなさそうな範囲にArchをバラ撒いておいて
Archを触れる自分の仕事を維持しようという狡猾な戦略だろ。
バージョンを上げてトラブルが発生しないような単純なケースなら
バージョンを維持した方が安定するんだからサポートの長いディストリを使うべき。
逆に最新のパッケージが必要になるケースでも実はArchは全く向いていない。
なぜなら最新パッケージの新機能を取り扱うようなピーキーなケースでは
バージョンをそこから更に上げると動作不良が発生する事が多々あるから
常にパッケージを最新に保つローリングリリースとは絶望的に相性が悪い。
どう転んでもArchを選択する積極的な理由は見当たらないね。
上下前次1-新書関写板覧索設栞歴
あと 375 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル
ぬこの手 ぬこTOP 0.013s