아치 리눅스는 서버 환경에 적합합니까?


30

Arch Linux가 서버 환경에 적합하다고 생각하십니까? 롤링 릴리스 모델과 단순성은 좋은 것으로 보입니다. 일단 설치 한 후에는 다른 배포판의 릴리스 모델처럼 다시 설치할 필요가 없기 때문입니다.

그러나 그 지속적인 업그레이드는 안정성 문제를 일으키지 않습니까? 최신 버전이지만 Arch Linux는 최신 STABLE 버전의 소프트웨어를 사용합니다.


최근 아치 일반 메일 목록 에서 웹 서버 스레드 로 아치 아래에 게시 된 유용한 토론 및 의견을 찾을 수 있습니다 .
mloskot 2016 년

답변:


33

아마도 서버 운영 체제로서 Arch의 가장 큰 문제는 업그레이드 후 언제 어디서 응용 프로그램이 중단 될 수 있는지 명확하지 않다는 것입니다. 종종 업그레이드를하기 전에 위키와 포럼에서 진행되는 작업을 따라야합니다. 데비안과 CentOS를 사용하면 STABLE 브랜치에서 수행되는 업그레이드가 보안 / 버그 수정이기 때문에 업그레이드로 인해 응용 프로그램이 중단되지 않을 것입니다.


27
그러나 업데이트를 롤아웃하기 전에 업데이트를 테스트해서는 안됩니까? 우리는 프로덕션에서 몇 개의 아치 박스를 실행하고 매주 정도의 내부 시스템에서 업데이트를 테스트합니다. 모든 것이 제대로 작동하면 업데이트를 롤아웃합니다.
Eric Coleman

13

아치를 좋아하지만 프로덕션 환경에는 사용하지 않습니다. 우선, 프로덕션 환경에서는 안정적이고 잘 테스트 된 무언가가 필요합니다. 또한 상당히 제거되었으므로 사용자 정의 스크립트를 작성하거나 수동으로 설정해야합니다 (시스템에서 실행중인 항목을 정확히 알고 있기 때문에 좋지만 구성하는 데 너무 많은 시간이 걸리기 때문에 매우 나쁩니다). 그 외에도 프로덕션 환경에서 널리 사용되지 않기 때문에 문제가 발생하면 데비안이나 페도라를 사용하는 경우 찾을 수있는 지원을 찾을 수 없습니다 (아치 커뮤니티는 훌륭하지만 솔직히 말하면 크지 않습니다. 데비안 또는 페도라로)

요약하면 데스크톱 환경에는 적합하지만 프로덕션 환경에는 적합하지 않다고 생각합니다.


6

예.

장점 :

  • 최소한의 시스템만으로도 특히 저가형 시스템 / VPS의 성능에 적합합니다. 불필요한 서비스는 없습니다-CentOS 7과 비교하여 베어 메탈을 실행하면서 나에게 적용 할 수없는 여러 VM 관련 서비스를 시작했습니다.

  • 최신 소프트웨어 및 큰 저장소; Repos에없는 것이있을 때 CentOS와 꽤 많은 시간을 잃어 버렸고 소스에서 컴파일하거나 타사 RPM / 저장소를 설치 한 다음이 타사 RPM이 있었기 때문에 종속성 지옥에 빠졌습니다. 공식 저장소에서의 업그레이드와 충돌합니다.

  • 다른 배포판 (우분투조차도)으로 전환하기 때문에 프로가 아니지만 적절한 배포판에서 기대할 수있는 것입니다.

  • 의미있는 네트워크 구성 도구. 데스크톱 급 네트워크 관리자 나 방화벽이 없습니다 (CentOS / RHEL 확인).

  • 깡통에 말한 것을 수행하는 패키지 관리자. 패키지 관리자는 방금 설치 한 서비스 (Ubuntu / Debian 참조)를 자동으로 구성하거나 시작하여 "도움말"을 시도하지 않습니다. 또한,보다 빠르며,보다 yum빠릅니다 apt-get.

  • 기본값을 사용하지 않고 사용자 정의를위한 많은 공간을 제공하는 설치 프로세스-CentOS / RHEL과 비교하여 LVM 및 스왑을 강제로 사용합니다. 항상 필요하지는 않습니다 (거의 실제로는 절대 아닙니다)

  • /usr/bin/python실제로 선사 시대의 파이썬 2.7이 아닌 최신 파이썬 3입니다. 그것은 대부분의 다른 배포판에서 항상 문제이며, 적어도 시스템 전체에서는이를 의존하지 않는 많은 앱이 중단되므로 쉽게 변경할 수 없습니다.

단점 :

  • 일부 업그레이드는 수동 개입이 필요하며 중단 될 수 있습니다. 실제 서버에서 롤아웃하기 전에 VM에 프로덕션 환경의 복제본을 보유하고 업그레이드를 테스트하는 것이 좋습니다.

  • 기본 작업 구성이 없습니다. apt-get을 실행하고 기본 안전하지 않은 LAMP 스택을 설치하여 깨지기 쉬운 취약한 PHP 앱을 배포하고 인터넷을 오염시키고 자하는 사람들에게는 좋지 않습니다. 물론 서비스를 시작하기 전에 구성 파일을 검토하도록 강요하는 것은 실제로 심각한 사람들에게 유리합니다.

  • SELinux 지원이 없습니다. GRSecurity와 RBAC가 있지만 익숙해 져서 미세 조정하려면 약간의 시간이 필요합니다.

나는 당신이 덜 지원한다는 사실에 동의하지 않습니다. 물론입니다. 그게 단점입니까? 내 의견으로는 아니다. 아치에는 거의 깨지지 않으며 아치에 익숙한 사람의 도움이 필요합니다. 일반적으로 지원이 필요한 경우 특정 소프트웨어에 대한 지원이 필요합니다.이 경우 개발자에게 물어보고 아치를 실행하고 있다는 사실은 관련이 없습니다.

나를 위해 아치를 사용하는 것은 CentOS와 네트워크 관리자, 방화벽 및 기타 불필요한 서비스를 사용하는 것보다 훨씬 쉽고 시간이 덜 걸립니다 (비활성화 될 수는 있지만 이미 시간이 낭비되었습니다). 또한 시스템을 설치했기 때문에 시스템에서 실행되는 모든 단일 서비스를 알고 있습니다. 시스템을 설치했지만 버그에 대해 신경 쓰지 않고 집으로 전화를 걸고 싶은 교활한 소프트웨어 는 없습니다 .


5

나는 항상 다음 중 하나를 제안합니다.

  • CentOS. 그것은 당신이 당신이 얻을 수있는 동안 매우 긴 지원주기 (7 년), 수 의미, 무료 RHEL 클론의 단지 매우, 매우 간단하므로 시스템 패치를 유지, 보안 수정 및 향상. 또한 많은 "상업용"소프트웨어가 RHEL을 대상으로하므로 CentOS에보다 쉽게 ​​설치할 수 있습니다. 단점 : apt / dpkg를 yum / rpm보다 선호하며, 최신 소프트웨어를 실행하기가 쉽지 않고 약간 스파르타 소프트웨어 선택

  • 우분투 LTS. 실제로 나는 그것을 사용하지 않았지만 긴 지원주기를 가지고 있으며 데비안 인입니다.

  • 데비안 테스트. 데비안이 가장 좋아하는 배포판은 정말 잘 작동하며 아주 잘 정리 된 어리석은 거대한 패키지 선택이 있습니다. 패치 된 상태를 유지하는 데 다소 시간이 걸리지 만 소프트웨어를 설치하는 것이 더 쉽습니다 (즉, 더 쉽게 패키지 할 수 있습니다).

아치 리눅스를 그 세 가지 중 하나에 사용하는 것이 좋습니다.


2
프로덕션 서버에서 데비안 테스트를 사용 하시겠습니까? 그건 말이되지 않습니다. 업데이트하는 동안 깨지는 것을 얼마나 자주 수정합니까?
Jason Berg

1
@Jason : 더 걱정스럽게도 데비안은 이제 테스트를위한 공식 보안 지원을 제공하지만, 테스트 용 보안 업데이트는 격리 시간은 줄어들지 만 제로가 아닌 격리 시간이 있으며 충족되지 않은 종속성으로 인해 지연 될 수 있기 때문에 안정적이거나 불안정한 것만 큼 좋지 않습니다.
Gilles 'SO- 악마 그만'

다소 최근의 소프트웨어를 실행하고 싶을 때 테스트를 시작합니다 (즉, CentOS에서 Rails 앱을 실행하는 것은 약간 어색하지만 데비안 테스트에서는 매우 쉽습니다 ...). 보안 업데이트 만 가져 오기 위해 debsecan을 사용하며 일반적으로 매우 안정적입니다. 하드 코어 프로덕션에 사용 했으므로 테스트 상자에서 업데이트를 롤아웃하기 전에 광범위한 테스트를 수행하고 싶습니다. 물론 CentOS 박스에서도 그렇게해야합니다 :-p
alex

1
"[데비안]은 패치를 유지하는 데 다소 시간이 오래 걸립니다" -최신 상태로 패치를 유지하는 것이 왜 더 어려울까요? CentOS 업데이트와 마찬가지로 단지입니다 apt-get upgrade. 어쩌면 내가 잃어버린 것…
Léo Lam

2
이 답변이 어떻게 "아키 리눅스가 서버 환경에 적합한가?"라는 질문을 어떻게 해결하는지는 잘 모르겠습니다. 세 가지 다른 배포판을 제안한 다음 독자들에게 아치 리눅스와 비교해 보라고 제안하는 것은 답이 아닙니다.
존 벤틀리

1

프로덕션 환경에서 2013 년부터 여러 아치 리눅스 서버를 실행하고 있으며 매력처럼 작동합니다.

물론 업데이트를 자주 실행하여 업데이트가 제대로 진행되고 업그레이드하기 전에 항상 archlinux 페이지를 확인해야합니다.

그러나 결국 RedHat / CentOS를 6에서 7 (거의 불가능)으로 업그레이드하거나 SLES / SLED를 11에서 12로 업그레이드하는 데 훨씬 더 많은 문제가 발생합니다.

때때로 약간의 업데이트가 발생하여 때때로 일부 작업이 발생하지만 지난 5 년 동안 큰 일이 없었습니다.

또한 커널, openssl, bash 또는 기타에서 보안 누출이있는 경우 며칠이 아닌 몇 시간이 아니라 몇 시간 내에 업데이트가있는 경우 항상 최신 상태입니다.

예를 들어 내 서버는 완전히 업그레이드되어 스펙터 v1, 스펙터 v2 및 멜트 다운으로부터 보호됩니다. 여기에 게시하는 사람의 1 %만이 세 가지 모두에 대해 서버를 보호하고 있다고 확신합니다.

빠르고 안전하며 안정적인 (!) 최신 소프트웨어를 사용하면 많은 문제를 해결할 수 있습니다.

서버에서 Archlinux를 사용하는 것이 좋습니다. 단점은 당신이하는 일을 알아야한다는 것입니다. Linux 배포판을 작성하고 작동하는 방법에 대한 기본 사항을 이해하려면 LFS 시스템을 한 번 이상 설치해야합니다.

서버 환경에서 Archlinux보다 견실 한 것을 발견 한 유일한 서버 시스템은 Gentoo였습니다. 700 일 동안 업데이트가없는 1 대의 젠투 시스템이 있었고 1 시간 후이 시스템은 최신 상태이며 가동 시간은 단일 재부트 일뿐입니다.

그러나 데비안 / 우분투, 레드햇, SUSE와 같은 다른 시스템은 배포판 업그레이드가있을 때 완전히 망칠 것입니다. RedHat은 배포판 업그레이드를 권장하지 않으며 공식 문서에 따라 다시 설치하는 것이 좋습니다.

따라서 RedHat은 Archlinux보다 업그레이드 안정성이 뛰어나지 만 큰 업그레이드를 얻지 못하기 때문입니다. 그리고 당신이 그들을 얻을 때, 당신은 망했다.


0

예를 들어,주의해야 할 점은 프로덕션 서버에서 pacman -Syu를 실행하고 파일 시스템에 장애가 발생할 경우 롤백 할 수있는 시스템 드라이브의 diff-image 백업을 유지해서는 안됩니다.

데비안 테스트 / sid보다 훨씬 더 유용합니다 (파손 웹이 훨씬 적음). 최첨단 패키지와 최소한의 설치를 원한다면 Arch는 최고의 배포판이지만 수동 관리에 많은 편의가 필요합니다.


0

서버 배포판의 주요 차이점은 보안 업데이트 만받는 반면 아치형에서는 패키지의 주요 개정판을 가져 와서 문제가 발생할 수 있다는 것입니다.

아치를 서버에 적합하게 만들려면 미러 (패키지를받는 곳)를 변경하기 만하면됩니다. 예를 들면 다음과 같습니다.

  • 아치 미러 : 소유자가 릴리스 한 후 첫 주 동안 사소한 / 주요 패키지 업데이트를받습니다.
  • manjaro-unstable : 아치 미러와 동일하지만 일부 패키지를 다시 확인합니다. 일부 주요 버그는 프로덕션 환경에 적용되지 않습니다.
  • manjaro-beta : 아치 미러와 동일하지만 모든 패키지가 세 번 검사됩니다. 대부분의 주요 버그는 생산에 영향을 미치지 않습니다.
  • manjaro-stable : 아치 미러와 동일하지만 패키지는 몇 달 동안 여러 번 검사됩니다. 사소한 버그가 거의 없어 프로덕션에 사용됩니다.

같은 방식으로 약간만 수정 된 서버용으로 특별히 설계된 미러를 사용하는 경우 서버에서 아치를 사용하는 것이 안전합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.