몇 가지 다른 분야에서 기술자로 일한 경험을 공유 할 것입니다 ...
(주의 : 이것은 Red Hat에 대한 이야기와 전문적으로 성장한 방법입니다)
2000-2002 년에 Linux를 전문적으로 다루기 시작했습니다. 이것은 Red Hat 및 Red Hat Professional Edition (6.x, 7.x, 8.0)을 광범위하게 채택하는 동안 이루어졌습니다 . 이들은 패키지 패키지 세트뿐만 아니라 무료로 다운로드 할 수있었습니다. 컴퓨터 소매점에서 쉽게 찾을 수 있습니다.
나에게 이것은 기업에서 등장하기 시작한 동일한 제품으로 애호가 및 가정 사용자를 참여시키는 이점 을 얻었습니다. 현재 필자의 작업은 상용 서버 (HP-UX, AIX 및 SCO)에서 Red Hat 플랫폼으로 고객 서버 시스템을 옮기는 것이 었습니다.
비용 절감은 상당했습니다! $ 100k + HP9000 PA-RISC 서버를 $ 40k Compaq ProLiant Intel 서버로 교체하는 것은 비용과 성능면에서 절대적인 승리였습니다.
그렇다면 왜 Red Hat입니까?
Red Hat은이 시장에서 처음으로 중요한 비즈니스, 공급 업체 및 하드웨어 지원을 얻었습니다. 대규모 응용 프로그램 공급 업체는 Red Hat을 대상 플랫폼으로 사용하여 거래를 마무리했습니다. 나와 같은 취미 사용자는 집에서 연마 한 기술을 업무 환경으로 쉽게 이전 할 수있었습니다. 커뮤니티가 성장하고있었습니다. Slashdot , Freshmeat 및 LAMP 스택이 결정되었습니다! 리눅스에게는 좋은 시간이었다.
이 시점에서 저는 독점 ERP 소프트웨어 솔루션을위한 플랫폼으로서 Linux 배포판의 개발 및 평가를 담당했습니다. 나는 Red Hat을 고수했다. 나는 종종 다른 배포판 ( Mandrake , SuSE , Debian , Gentoo )을 시도하지만 패키징, 하드웨어 지원 (서버 또는 주변 장치), (규모) 커뮤니티 또는 다른 거래 차단기 와 관련된 문제를 찾을 것 입니다.
예 : Digi Serial 확장 PCI-X 카드 및 Esker VSIfax 프로덕션 팩스 소프트웨어가 장착 된 Compaq / HP ProLiant 하드웨어를 사용 하고 있었습니다 . 후자는 두 Red Hat 운영 체제에 대한 드라이버 만 지원했습니다. 어떤 경우에는 소프트웨어가 바이너리 또는 RPM 형식으로 만 제공되어 다른 Linux 변형에서 쉽게 사용할 수 없습니다.
정보 기술 세계에서 모멘텀 문제
아무도는 권장 하나 싶어 지는 결국 고아가됩니다 솔루션이나 프로젝트를, 그래서 당신은 안전한 선택을 고수. 저는 안정적으로 작동하고 여러 계층의 지원을 필요로하는 기술 스택을 관리하고있었습니다. 그 시점에서 다른 배포판을 선택하면 좋을 것이다. 되었습니다. 책임지지 않는.
Red Hat 허니문은 2003 년 소프트웨어 의 전문 판이 중단되면서 종료되었습니다 . Red Hat Enterprise Linux 가 대체품으로 사용되었으며 비용 (비용이 많이 드는 서브 스크립 션 기반 모델), 접근성 (사용자 기반 및 커뮤니티 축소) 및 미래에 대한 일반적인 혼란으로 인해 약간의 수하물이 제공되었습니다.
젠투, 데비안 및 SuSE를 재평가하면서 대안을 찾기 시작했습니다. 기술 스택의 모든 구성 요소를 올바르게 지원할 수 없었습니다. Red Hat 에코 시스템을 고수했습니다 ... Red Hat Enterprise Linux와 관련된 비용이 많이 들어감에 따라 수명이 다한 이후 몇 년 동안 수정 된 Red Hat 8.0을 실행하게되었습니다 . RHEL 복제본이 성숙해질 때까지 ( Whitebox Linux 및 이후 CentOS ) 표준에서 벗어나기위한 준비를 마쳤습니다.
레드햇 파생 상품의 가장 큰 장점이었고 입니다 유료 RHEL 버전과 바이너리 호환성. RHEL과 CentOS간에 적절한 변환을 수행 할 수도 있으며 그 반대도 가능합니다. 다음 경력을 쌓을 때까지 RHEL과 같은 시스템으로 계속 작업했습니다.
나중에 중요한 금융 거래 시스템에서 R & D 및 Linux 엔지니어링을 담당하는 고주파 금융 거래 업계 에서 나 자신을 발견했습니다 . 이 세상에서 강조 하는 것은 세심한 테스트와 튜닝을 통한 속도 였습니다 . 다시 한 번 하드웨어 지원이 핵심이었습니다. 특정 네트워크 카드 , 특수 하드웨어가 필요합니다RHEL 또는 RHEL 유사 시스템에 대해서만 인증 된 서버 하드웨어 또는 응용 프로그램 라이브러리 다른 Linux 변형을 위해 컴파일 할 수있는 경우에도 커뮤니티 요소가 발생했습니다. 문제를 조사해야 할 시점이되었을 때, 종종 Red Hat Bugzilla 보고서의 메모 나 의견으로 추적 될 수있는 문제이거나 때로는 다음 릴리스에 대한 패치 나 요청을 제출하기도합니다. .
지연 시간이 짧은 네트워킹 및 커널 조정에 대해 알아보기 시작하면서 주식 RHEL 커널과 RHEL MRG 실시간 커널 을 분석하기 시작했습니다 . 나는 릴리스에있을 때 얼마나 많은 작업을 보았습니다 ... vanilla kernel.org 커널에 200 개 이상의 패치. 의견을 읽고 메모를 작성하십시오. sysctl매개 변수 노출 또는 더 많은 제정신 기본값이 적용되는 것과 같은 작은 것들이있을 수 있습니다 . Red Hat은 이러한 문제를 패치, 테스트 및 수정하도록 사람들에게 비용을 지불합니다. 다른 Linux 배포판과 동일한 노력을 보지 못했습니다 ... 엔터프라이즈 플랫폼이 수년간 실질적인 보안, 버그 수정 및 백 포트 지원을 보장한다는 사실을 추가하십시오 .
그래서 결국 서버 와 데스크탑 에서 거의 모든 젠투 인 다른 금융 회사로 이사했습니다 . 그것은 저에게 재앙이었습니다. Red Hat 및 CentOS 환경에서 나온 Gentoo 설정에서 수많은 안정성 및 관리 문제가 발생했습니다. 버전 관리가 가장 큰 문제 였지만 커뮤니티 지원 감소와 실제 테스트 부족도 우려되었습니다. 타사 소프트웨어 중 일부가 필요하기 때문에 RHEL을 환경에 도입하기 시작했습니다 ...
그러나 문제가 발생했습니다 ... 개발자들이 Gentoo에 익숙했고 핵심 라이브러리 및 응용 프로그램 버전에 대한 비교적 쉬운 업그레이드 경로를 가지고있었습니다. Red Hat Enterprise Linux가 표준화 한 고정 메이저 버전을 갖도록 조정할 수 없었습니다. GLIBC 2.7을 RHEL 5.x에 이식 할 수없는 이유 또는 특정 컴파일러 또는 라이브러리 버전을 사용할 수없는 이유에 대한 질문으로 개발 및 릴리스 프로세스에 어려움이 있었습니다 . RHEL / CentOS의 주요 버전 간 업그레이드에는 기본적으로 전체 재 구축이 필요 하다는 말을 들었을 때 솔루션에 대한 많은 신뢰를 잃었습니다.
이 시점에서 필자는 Red Hat이 최첨단 기술을 원했던 개발자에게는 너무 느리게 움직이고 있음을 깨달았습니다. RHEL 6.x는 매우 필요하고 환영받는 업그레이드 였지만 DevOps 원칙에 가입 한 신생 기업 및 회사와의 인터뷰를 시작하면이 주제가 더욱 분명해졌습니다 .
오늘날 ...
점점 더 많은 개발자와 Linux 사용자가 비 Red Hat, 비 SuSE, 비 기업 Linux 환경에서오고 있습니다.
- 그들은 우분투 또는 데비안을 사용하고 있습니다 ...
- 그들은 구식 하드웨어 나 대규모 공급 업체 지원을 다룰 필요가 없었습니다.
- 그들은 처음부터 자체 응용 프로그램을 작성하고 있습니다 (자체 지원).
- 가상화 및 클라우드 컴퓨팅은 하드웨어 계층을 추상화하므로 펑키 RAID 컨트롤러 드라이버, PCI-X 주변 장치 또는 이진 분산 관리 에이전트에 대한 걱정도 레이더에 없습니다.
- 이 사용자들은 익숙한 도구와 사용자 영역을 원합니다.
따라서 충돌이 발생합니다 ...이 사용자는 왜 애플리케이션 또는 라이브러리 버전으로 제한되는지 이해하지 못합니다. 구식 관리자는 여전히 새로운 패러다임에 적응하고 있습니다. 인수 것 종교에 뿌리를 할 정말 사람들이 각각의 스킬을 개발하는 방법에 불과 기능입니다.
나는 오늘 다음과 같은 수석 DevOps Linux 엔지니어 직책 광고를 보았습니다.
데비안 기반 Linux 배포판에서 숙련 된 전문가 여야합니다 (우분투 및 변형은 가능합니다. Red Hat은 통과 가능 하지만 선호 하지는 않습니다 )
그래서 나는 두 가지 방법으로 작동한다고 생각합니다 ... 관리하고있는 800 CentOS 서버가 우분투로 변환 될 예정이기 때문에 취업 기회를 피했습니다. 물론, 리눅스는 리눅스입니다.하지만 저는 제가 효과적 일 줄은 몰랐습니다 ... 데비안 설치에 혼란을 겪고 RPM 기반 배포판이 사용되기를 바랍니다. 다양한 플랫폼의 장점에 대해 논쟁을 벌였습니다 (일반적으로 목록의 맨 아래에 Gentoo를 배치합니다).
환경에 적합한 것은 무엇입니까? 따라 다릅니다. 저는 시스템 엔지니어가 의사 결정을 내리는 회사와 개발자가 왕성한 조직에있었습니다. 시스템을 지원하는 개발자와 사람들이 플랫폼에 동의하는 것이 최선의 방법이라고 생각합니다. 그러나 그 이외의 장기 지원, 유용성, 커뮤니티 및 가장 적합한 방식으로 애플리케이션 스택을 수용 할 수있는 것이 무엇인지 생각해보십시오.
유능한 개발자는 RHEL 또는 Debian과 같은 환경에서 작업 할 수 있어야합니다. 그리고 개발 플랫폼은 프로덕션 환경을 반영해야합니다. 거기에서 간다 ...