Amazon EC2에서 첫 번째 웹 사이트를 설정하고 사용할 배포판을 결정하려고합니다. 과거에는 Redhat과 CentOS를 사용했지만 시스템에 대한 편견이 없으며 가장 좋은 것을 사용하고 싶습니다 (과거에는 부분적으로 관리되는 서버가 있었으므로 너무 많은 서버를 수행하지 않았습니다) 최근까지 관리). 이 웹 사이트는 PHP와 MongoDB로 작성된 웹 응용 프로그램입니다.
Amazon Linux에 대해 설명 된 경량 OS를 사용한다는 아이디어가 마음에 들지만 팀이 서버 OS에만 집중 한 다른 옵션과 비교하여 Ubuntu 또는 다른 옵션과 비교하여 호환성 / 업데이트가 발생할 수 있다고 걱정합니다. 어떤 충고?
답변:
나는 비슷한 상황에 있었다. 완벽하게 관리되는 전용 서버, LAMP, CentOS. 그런 다음 EC2로 전환하기로 결정했습니다. 또한 시스템 또는 Linux 관리 경험이 거의 없습니다. 우분투에 대한 경험이 거의 없기 때문에 소위 더 나은 OS라고 말할 수는 없습니다.
Rightscale, Alestic, Scalr 및 Amazon의 최소 OS 설치로 사전 구축 된 AMI를 시험해 보았습니다. 나는 먼저 2010.11.01 버전을 사용하여 Amazon Linux 위에 내 자신의 AMI를 모두 구축했으며, 이제 모든 사용자 지정 AMI를 Amazon Linux 버전 2011.03.01로 마이그레이션했습니다.
다른 AMI 공급자와 Amazon Linux AMI를 함께 사용하기로 한 결정은 쉽지 않았습니다. 나는 최종 결정을 내리기 한 달 전에 가까운 곳에서 놀았고 다른 설정을 테스트했습니다. 결국 CentOS를 사용하고 싶었 기 때문에 기본적으로 한 가지로 요약되었습니다. EC2를 설계, 구축 및 유지 관리하는 사람들보다 OS에 어떤 하드웨어 관련 종속성이 포함되어야하는지 아는 사람이 누구인지 더 잘 알았습니다. Rightscale, Scalr 또는 Alestic에 반대하는 것은 없습니다.
6 개월 후, 도로에서 약간의 충돌이 있었지만 Amazon의 Linux는 상당히 안정적이었습니다. 비록 소스 저장소에서 사용하는 일부 소프트웨어 (예 : php 5.3, MySQL 5.5 등)를 컴파일하기로 결정했지만 아마존은 패키지 리포지토리에서 유지 관리하는 사전 구축 된 패키지에 문제가 발생했습니다.
Amazon Linux는 Fedora 또는 Debian Testing (다양한)과 같은 롤링 배포판입니다. 내 생각에 그것은 어떤 생산 제품에도 적합하지 않습니다. 더 많은 사람들이 이것을 깨닫지 못하는 것에 놀랐습니다. 즉, 450 일 전에 Amazon Linux 인스턴스를 시작하고 오늘 업데이트를 수행하는 경우 완전히 다른 릴리스에서 업데이트를 가져옵니다. 새 릴리스가 만들어지면 버퍼 시간이 없어 즉시 새 릴리스에서 업데이트를 가져 오기 시작합니다. 당신이 상상할 수 있듯이, 이것은 일련의 의존성을 가져올 수 있으며, 일을 중단시키는 경향이 있습니다. 이러한 이유로 본질적으로 관리 할 수 없습니다. 절대 엉망이 아닌 업데이트 정책에는 이와 같은 작업을 수행 할 수 없습니다. 심각한 일에 Amazon Linux를 사용하지 마십시오.
데비안 스 테이블 또는 CentOS와 마찬가지로 우분투 LTS는 훌륭한 선택입니다. 이 모든 것들이 동일한 릴리스에 대한 수년간의 업데이트를 제공합니다.
Amazon Linux 에는 버그 추적 시스템 도 없습니다 . 사용자는 패키지에 대해 버그를 신고하려면 AWS 개발자 포럼에 질문을 게시해야합니다! 버그를 검색하는 방법도 없습니다. 이것은 거의 모든 사람에게 큰 문제입니다.
Amazon Linux는 불필요하게 소스 패키지를 검색하기가 매우 어렵습니다.
이 질문이 작성된 이후, Amazon은 Amazon Linux AMI 2011.09에 대해 완전히 개정 되었으며 CloudFormation 및 Amazon 도구의 모든 부트 스트랩이 포함되었습니다.
또한 yum빠르고 가벼운 경우 regin에 Nginx 및 PHP-FPM이 포함되어 있습니다.
http://aws.amazon.com/amazon-linux-ami/latest-release-notes/ 에서 최신 릴리스를 확인 하십시오.
또한 보안 업데이트를 주시하십시오 : http://aws.amazon.com/amazon-linux-ami/security-bulletins/
기본 AMI는 실제로 필요한 서비스를 부트 스트랩하는 데 필요한 도구 만 갖춘 베어 본 서버이므로 일반적으로 걱정할 필요가 없습니다.
이미 RHEL / CentOS에 대해 잘 알고 있다면이를 고수 할 것입니다. 웹앱 서버에는 "최고의"배포판이 없습니다. 가장 친숙한 도구와 규칙이 있습니다.
비록 우분투가 이러한 벤치 마크 에서 더 나아지 긴하지만 테스트 자체는 우분투 우승에 기여하며, 그 차이는 크지 않은 것으로 보입니다.
저는 최근 자동 업데이트 와이 질문의 Quora 버전 에서 Steven과 Ethan이보고 한 Ubuntu AMI 버그 때문에 Amazon Linux를 주로 선택했습니다 .
빨리 친숙해지고 싶다면 우분투를 사용하지 않아도 많은 것을 설치하는 것을 좋아합니다. 일반적으로 라이브 웹 서버에서는 이런 종류의 일을하고 싶지 않습니다! 또한 사람들은 RedHat, CentOS 및 Debian 중에서 선택하는 것이 좋습니다. 하드 코어 기술자는 모든 것이 완전히 안전하고 테스트되지 않았기 때문에 우분투가 라이브 서버 환경에 적합하지 않다고 주장합니다.
두통이 적기 때문에 내 선택은 우분투 일 것입니다. 웹 서버에는 꽤 많은 다른 배포판을 사용했지만 우분투에서는 방화벽 규칙과 일을 쉽게 변경할 수 있습니다.
유일한 다른 점은 우분투가 리소스 사용량이 조금 더 많기 때문에 CentOS는 아마존의 가격 책정 방법에 따라 한 달에 몇 달러를 절약 할 수 있습니다!
귀하의 경우 CentOS / RHEL에 대한 친숙 함이 다른 고려 사항보다 우선합니다.
내가 작업하는 시스템은 주로 새로운 기술과 새로운 버전을 사용하는 새로운 소프트웨어 인 에지에있었습니다. 이를 위해 우분투가 더 나은 선택입니다. 소스 코드에서 패키지를 작성하는 것을 피하고 Ubuntu의 패키지는 잘 유지 관리되며 (물론 완벽하지는 않습니다) 표준 리포지토리에는 필요한 항목이 있고, 그렇지 않은 경우에는 즉시 사용할 수있는 리포지토리가 있습니다. 몇 달 후에 문제가 해결되는 경향이 있기 때문에 최신 버전에서 한 가지 수정을 유지하는 경향이 있습니다.