고아 서비스: (마이크로)서비스 아키텍처의 단점

Banki.ru 포털 운영 이사 Andrey Nikolsky가 작년 컨퍼런스에서 연설했습니다. DevOpsDays 모스크바 고아 서비스 정보: 인프라에서 고아 서비스를 식별하는 방법, 고아 서비스가 왜 나쁜지, 어떻게 해야 하는지, 아무것도 도움이 되지 않는 경우 어떻게 해야 하는지.

컷 아래에는 보고서의 텍스트 버전이 있습니다.

안녕하세요 동료들! 제 이름은 Andrey이고 Banki.ru의 운영 책임자입니다.

우리는 대규모 서비스를 가지고 있습니다. 이것은 모놀리식 서비스이며, 보다 고전적인 의미의 서비스가 있고 매우 작은 서비스도 있습니다. 나는 노동자-농민 용어로 서비스가 단순하고 작으면 마이크로 서비스이고, 아주 단순하고 작지 않으면 그냥 서비스라고 말합니다.

서비스의 장점

서비스의 장점을 빠르게 살펴보겠습니다.

첫 번째는 스케일링입니다. 서비스에 대한 작업을 신속하게 수행하고 생산을 시작할 수 있습니다. 트래픽을 수신하고 서비스를 복제했습니다. 더 많은 트래픽이 있고 이를 복제하여 함께 생활합니다. 이것은 좋은 보너스이며, 원칙적으로 우리가 시작했을 때 우리가 이 모든 일을 하는 이유가 가장 중요한 것으로 간주되었습니다.

둘째, 격리된 개발은 여러 개발 팀이 있고 각 팀에 여러 개발자가 있고 각 팀이 자체 서비스를 개발하는 경우입니다.

팀에는 뉘앙스가 있습니다. 개발자는 다릅니다. 그리고 예를 들어, 눈송이 사람들. 저는 이것을 Maxim Dorofeev에게서 처음 봤습니다. 때때로 눈송이 사람들은 어떤 팀에는 있고 다른 팀에는 없습니다. 이로 인해 회사 전체에서 사용되는 다양한 서비스가 약간 고르지 않게 됩니다.

사진을 보세요. 이 사람은 좋은 개발자이고 손이 크고 많은 일을 할 수 있습니다. 가장 큰 문제는 이 손이 어디서 나오는가이다.

서비스를 통해 다양한 작업에 더 적합한 다양한 프로그래밍 언어를 사용할 수 있습니다. 일부 서비스는 Go에 있고, 일부는 Erlang에, 일부는 Ruby에, 일부는 PHP에, 일부는 Python에 있습니다. 일반적으로 매우 광범위하게 확장할 수 있습니다. 여기에도 뉘앙스가 있습니다.

서비스 지향 아키텍처는 주로 DevOps에 관한 것입니다. 즉, 자동화가 없으면 배포 프로세스도 없고, 수동으로 구성하면 서비스 인스턴스마다 구성이 변경될 수 있고, 뭔가를 하려면 그곳으로 가야 해서 지옥에 가는 것입니다.

예를 들어, 20개의 서비스가 있고 수동으로 배포해야 하며, 20개의 콘솔이 있고 동시에 닌자처럼 "Enter" 키를 누릅니다. 별로 좋지 않습니다.

테스트 후 서비스가 있고(물론 테스트가 있는 경우) 프로덕션에서 작동하도록 파일로 마무리해야 하는 경우에도 나쁜 소식이 있습니다.

특정 Amazon 서비스에 의존하고 러시아에서 일한다면 두 달 전에 "주위의 모든 것이 불타고 있습니다. 저는 괜찮아요. 모든 것이 멋집니다."라는 말을 들은 적이 있을 것입니다.

우리는 Ansible을 사용하여 배포를 자동화하고, Puppet을 융합에 사용하고, Bamboo를 사용하여 배포를 자동화하고, Confluence를 사용하여 모든 것을 설명합니다.

보고서는 기술 구현에 관한 것이 아니라 상호 작용 관행에 관한 것이기 때문에 이에 대해 자세히 설명하지 않겠습니다.

예를 들어 서버의 Puppet은 Ruby 2에서 작동하지만 일부 애플리케이션은 Ruby 1.8용으로 작성되어 함께 작동하지 않는 문제가 있었습니다. 문제가 발생했습니다. 그리고 하나의 시스템에서 여러 버전의 Ruby를 실행해야 하는 경우 일반적으로 문제가 발생하기 시작합니다.

예를 들어, 우리는 각 개발자에게 우리가 가지고 있는 거의 모든 것, 개발할 수 있는 모든 서비스가 있는 플랫폼을 제공하여 그가 격리된 환경을 갖고 이를 깨고 원하는 대로 구축할 수 있도록 합니다.

무언가를 지원하는 특별히 컴파일된 패키지가 필요한 경우가 있습니다. 꽤 힘들다. Docker 이미지의 무게가 45GB라는 보고서를 들었습니다. 물론 Linux에서는 더 간단하고 모든 것이 더 작지만 여전히 공간이 충분하지 않습니다.

글쎄, 프로젝트의 한 부분이 한 버전의 라이브러리에 의존하고 프로젝트의 다른 부분이 다른 버전에 의존하며 라이브러리가 전혀 함께 설치되지 않는 경우 충돌하는 종속성이 있습니다.

PHP 5.6에는 사이트와 서비스가 있지만 부끄럽지만 무엇을 할 수 있습니까? 이것은 우리의 하나의 사이트입니다. PHP 7에는 사이트와 서비스가 더 많고 부끄럽지 않습니다. 그리고 각 개발자는 자신이 행복하게 본 자신의 기반을 가지고 있습니다.

회사에서 하나의 언어로 작성한다면 개발자당 XNUMX개의 가상 머신이 정상적으로 들립니다. 프로그래밍 언어가 다르면 상황이 더욱 악화됩니다.

여기에는 사이트와 서비스가 있고, Go에 대한 또 다른 사이트, Ruby에 대한 하나의 사이트, 그리고 그 옆에 다른 Redis에 대한 사이트가 있습니다. 결과적으로 이 모든 것이 지원을 위한 대규모 필드로 바뀌고 항상 일부는 중단될 수 있습니다.

따라서 우리는 프로그래밍 언어의 이점을 다른 프레임워크의 사용으로 대체했습니다. PHP 프레임워크는 매우 다르고 기능, 커뮤니티 및 지원도 다르기 때문입니다. 그리고 이미 서비스를 준비할 수 있도록 서비스를 작성할 수도 있습니다.

각 서비스에는 자체 팀이 있습니다.

수년에 걸쳐 구체화된 우리의 주요 장점은 각 서비스에 자체 팀이 있다는 것입니다. 이는 대규모 프로젝트에 편리하며 문서화 시간을 절약할 수 있고 관리자는 프로젝트를 잘 알고 있습니다.

지원팀에서 쉽게 작업을 제출할 수 있습니다. 예를 들어, 보험 서비스가 중단되었습니다. 그리고 즉시 보험을 담당하는 팀이 문제를 해결하러 갑니다.

하나의 원자 서비스가 있으면 신속하게 무언가를 망칠 수 있기 때문에 새로운 기능이 빠르게 생성되고 있습니다.

그리고 당신이 서비스를 중단했는데 이런 일이 불가피하게 발생하더라도 당신은 다른 사람의 서비스에 영향을 주지 않았고, 다른 팀의 개발자도 당신에게 달려와서 "아, 그러지 마"라고 말하지도 않았습니다.

언제나 그렇듯이 뉘앙스가 있습니다. 우리에게는 안정적인 팀이 있고 관리자는 팀에 못 박혀 있습니다. 명확한 문서가 있으며 관리자는 모든 것을 면밀히 모니터링합니다. 관리자가 있는 각 팀에는 여러 가지 서비스가 있으며 특정 역량 포인트가 있습니다.

팀이 떠 있는 경우(우리도 가끔 사용함) '스타 맵'이라는 좋은 방법이 있습니다.

서비스와 사람들의 목록이 있습니다. 별표는 그 사람이 이 서비스의 전문가라는 것을 의미하고, 책은 그 사람이 이 서비스를 연구하고 있다는 것을 의미합니다. 그 사람의 임무는 책을 별표로 교환하는 것입니다. 그리고 서비스 앞에 아무것도 쓰여지지 않으면 문제가 시작됩니다. 이에 대해 더 자세히 설명하겠습니다.

고아 서비스는 어떻게 나타나나요?

첫 번째 문제, 인프라에서 고아 서비스를 얻는 첫 번째 방법은 사람들을 해고하는 것입니다. 업무를 평가하기 전에 비즈니스에서 마감일을 맞추는 사람이 있었나요? 때로는 마감일이 촉박하고 문서화할 시간이 충분하지 않은 경우가 있습니다. "우리는 서비스를 프로덕션 단계로 넘겨야 하고, 그런 다음 서비스를 추가할 것입니다."

팀 규모가 작다면 모든 것을 작성하는 개발자가 한 명 있고 나머지는 날개에 있는 경우가 있습니다. "기본 아키텍처를 작성했으니 인터페이스를 추가해 보겠습니다." 예를 들어, 어느 시점에 관리자가 떠납니다. 그리고 이 기간 동안 관리자가 떠나고 아직 새 관리자가 임명되지 않은 경우 개발자는 서비스가 어디로 가고 그곳에서 무슨 일이 일어나고 있는지 스스로 결정합니다. 그리고 우리가 알고 있듯이(몇 장의 슬라이드로 돌아가겠습니다) 일부 팀에는 눈송이 직원이 있고 때로는 눈송이 팀 리더가 있습니다. 그러다가 그는 그만두고 우리는 고아 서비스를 받게 됩니다.

동시에 지원 및 비즈니스 작업은 사라지지 않고 백로그에 남게 됩니다. 서비스 개발 중에 아키텍처 오류가 발생한 경우에도 백로그에 포함됩니다. 서비스가 서서히 악화되고 있습니다.

고아를 식별하는 방법은 무엇입니까?

이 목록은 상황을 잘 설명합니다. 인프라에 대해 누가 배웠습니까?

문서화된 해결 방법 정보: 서비스가 있고 일반적으로 작동하며 작업 방법에 대한 두 페이지짜리 설명서가 있지만 내부에서 어떻게 작동하는지 아는 사람은 없습니다.

또는 예를 들어 일종의 링크 단축기가 있습니다. 예를 들어, 현재 다양한 서비스에서 다양한 목적으로 사용되는 세 가지 링크 단축기가 있습니다. 이것은 단지 결과일 뿐입니다.

이제 나는 당연한 것의 선장이 될 것이다. 무엇을 해야 합니까? 먼저, 서비스를 다른 관리자, 다른 팀으로 이전해야 합니다. 팀 리더가 아직 종료되지 않은 경우 다른 팀에서 서비스가 고아와 같다는 것을 이해하면 이에 대해 최소한 이해하는 사람을 포함해야 합니다.

가장 중요한 것은 혈액으로 작성된 양도 절차가 있어야 한다는 것입니다. 우리의 경우에는 일반적으로 이를 모니터링합니다. 작동하려면 모든 것이 필요하기 때문입니다. 관리자는 정보가 신속하게 전달되어야 하며, 나중에 발생하는 일은 더 이상 그들에게 그다지 중요하지 않습니다.

고아를 만드는 다음 방법은 “아웃소싱해서 더 빨리 하고, 팀에 넘겨주겠다”는 것이다. 팀 내에서 모든 사람이 몇 가지 계획을 가지고 있다는 것은 분명합니다. 종종 비즈니스 고객은 아웃소싱 업체가 회사의 기술 부서와 동일한 작업을 수행할 것이라고 생각합니다. 그들의 동기는 다르지만. 아웃소싱에는 이상한 기술 솔루션과 이상한 알고리즘 솔루션이 있습니다.

예를 들어, 예상치 못한 다양한 장소에 스핑크스가 있는 서비스가 있었습니다. 내가 무엇을 해야 했는지는 나중에 말씀드리겠습니다.

아웃소싱 업체에는 자체 작성된 프레임워크가 있습니다. 이것은 모든 종류의 것을 찾을 수 있는 이전 프로젝트의 복사-붙여넣기를 사용한 순수 PHP입니다. 배포 스크립트는 일부 복잡한 Bash 스크립트를 사용하여 일부 파일의 여러 줄을 변경해야 할 때 큰 단점이며 이러한 배포 스크립트는 일부 세 번째 스크립트에 의해 호출됩니다. 결과적으로 배포 시스템을 변경하고 다른 것을 선택하고 홉하지만 서비스가 작동하지 않습니다. 왜냐하면 서로 다른 폴더 사이에 8개의 링크를 더 넣어야 했기 때문입니다. 또는 수천 개의 레코드가 작동하지만 수십만 개의 레코드가 더 이상 작동하지 않는 경우도 있습니다.

나는 계속해서 선장을 맡을 것이다. 아웃소싱 서비스를 수락하는 것은 필수 절차입니다. 아웃소싱 서비스가 도착했지만 어느 곳에서도 받아들여지지 않은 적이 있습니까? 물론 이것은 고아 서비스만큼 인기가 없지만 여전히 그렇습니다.

서비스를 확인하고, 서비스를 검토하고, 비밀번호를 변경해야 합니다. 그들이 우리에게 서비스를 제공했을 때 "if login == 'admin' && 비밀번호 == 'admin'..."이라는 관리자 패널이 있고 코드에 바로 쓰여 있는 경우가 있었습니다. 우리는 앉아서 생각하는데, 사람들이 2018년에 이런 글을 쓴다고?

저장 용량 테스트도 꼭 필요한 일이다. 이 서비스를 어딘가에서 프로덕션에 투입하기 전에도 수십만 개의 레코드에서 어떤 일이 일어날지 살펴봐야 합니다.

개선을 위해 서비스를 보내는 것은 부끄러운 일이 아닙니다. 귀하가 "우리는 이 서비스를 수락하지 않을 것입니다. 20가지 작업이 있으므로 수행한 다음 수락하겠습니다"라고 말하면 이는 정상입니다. 관리자를 세우거나 사업이 돈을 낭비하고 있다는 사실로 인해 양심이 상해서는 안됩니다. 그러면 사업체는 더 많은 비용을 지출하게 됩니다.

파일럿 프로젝트를 아웃소싱하기로 결정한 사례가 있었습니다.

정시에 배송되었으며 이것이 유일한 품질 기준이었습니다. 그래서 우리는 더 이상 파일럿이 아니었던 또 다른 파일럿 프로젝트를 만들었습니다. 이러한 서비스는 승인되었으며 관리 수단을 통해 여기에 귀하의 코드가 있고 여기에 팀이 있으며 여기에 귀하의 관리자가 있다고 말했습니다. 실제로 해당 서비스는 이미 수익을 창출하기 시작했습니다. 동시에 실제로 그들은 여전히 ​​​​고아이며 아무도 자신의 작업 방식을 이해하지 못하며 관리자는 자신의 업무를 부인하기 위해 최선을 다합니다.

게릴라 개발이라는 또 다른 훌륭한 개념이 있습니다. 일부 부서(주로 마케팅 부서)에서 가설을 테스트하고 전체 서비스를 아웃소싱하도록 주문하는 경우. 트래픽이 쏟아지기 시작하고 문서를 닫고 계약자와 문서에 서명한 다음 작업을 시작하고 이렇게 말합니다. 우리는 “오빠, 어떻게 그럴 수가 있어?”라고 했어요.

그리고 고아 서비스를 얻는 또 다른 방법은 어떤 팀이 갑자기 부하를 느끼면 경영진이 "이 팀의 서비스를 다른 팀으로 이전하자, 부하가 더 적다"라고 말하는 것입니다. 그리고 XNUMX번째 팀에 이적하고 감독도 바꾸겠습니다. 그리고 결국 우리는 다시 고아가 생겼습니다.

고아들에게 무슨 문제가 있는 걸까요?

모르시는 분 계시겠지만, 발사 5분 만에 침몰한 것으로 유명한 스웨덴에서 건조된 전함 와사(Wasa)입니다. 그런데 스웨덴 왕은 이에 대해 누구도 처형하지 않았습니다. 그러한 선박을 만드는 방법을 모르는 두 세대의 엔지니어가 제작했습니다. 자연스러운 효과.

그런데 배는 예를 들어 왕이 이미 폭풍 속에서 어딘가에 타고 있었을 때 훨씬 더 나쁜 방식으로 침몰했을 수 있습니다. 그래서 그는 즉시 익사했습니다. Agile에 따르면 일찍 실패하는 것이 좋습니다.

일찍 실패하면 일반적으로 문제가 없습니다. 예를 들어 수락하는 동안 수정을 위해 전송되었습니다. 그러나 이미 생산에 실패하고 돈이 투자되면 문제가 발생할 수 있습니다. 비즈니스에서 소위 말하는 결과.

고아 서비스가 위험한 이유:

• 서비스가 갑자기 중단될 수 있습니다.
• 서비스를 수리하는 데 시간이 오래 걸리거나 전혀 수리되지 않습니다.
• 안전 문제.
• 개선 및 업데이트에 문제가 있습니다.
• 중요한 서비스가 중단되면 회사의 평판이 훼손됩니다.

고아 서비스는 어떻게 해야 하나요?

해야 할 일을 다시 반복하겠습니다. 첫째, 서류가 있어야 합니다. Banki.ru에서 7년 동안 근무하면서 테스터는 개발자의 말을 받아들여서는 안 되고 운영도 모든 사람의 말을 받아들여서는 안 된다는 점을 배웠습니다. 확인해야합니다.

둘째, 잘 받아들여지지 않은 서비스에는 아무도 언급하지 않은 종속성이 포함되어 있기 때문에 상호 작용 다이어그램을 작성해야 합니다. 예를 들어 개발자는 일부 Yandex.Maps 또는 Dadata의 키에 서비스를 설치했습니다. 무료 한도가 부족하고 모든 것이 손상되었으며 무슨 일이 일어났는지 전혀 알 수 없습니다. 이러한 모든 갈퀴는 설명되어야 합니다. 서비스는 Dadata, SMS 등을 사용합니다.

셋째, 기술 부채를 다루는 것입니다. 어떤 종류의 목발을 짚거나 서비스를 수락하고 어떤 일을 해야 한다고 말할 때, 그 일이 확실히 끝났는지 확인해야 합니다. 왜냐하면 그러면 작은 구멍이 그다지 작지 않아 그 구멍을 통과하게 될 수도 있기 때문입니다.

건축 작업으로는 스핑크스에 대한 이야기를 나눴습니다. 서비스 중 하나는 Sphinx를 사용하여 목록을 입력했습니다. 페이지가 매겨진 목록이지만 매일 밤 다시 색인이 생성되었습니다. 두 개의 색인으로 구성되었습니다. 하나는 매일 밤 큰 색인이 생성되었고, 나사로 고정된 작은 색인도 있었습니다. 매일 폭탄이 터졌는지 안 터졌는지 50%의 확률로 계산 중에 지수가 충돌했고 우리 뉴스가 메인 페이지에서 업데이트를 중단했습니다. 처음에는 인덱스를 다시 인덱싱하는 데 5분이 걸렸다가 나중에 인덱스가 늘어나 어느 시점부터 다시 인덱스하는 데 40분이 걸리기 시작했습니다. 이 부분을 잘라내자 우리는 안도의 한숨을 쉬었습니다. 시간이 조금 더 지나면 우리 인덱스가 풀타임으로 다시 색인화될 것이 분명했기 때문입니다. 이것은 우리 포털의 실패가 될 것입니다. XNUMX시간 동안 아무 소식도 없습니다. 그게 전부입니다. 비즈니스가 중단되었습니다.

고아 서비스 작업 계획

사실, 데브옵스는 의사소통에 관한 것이기 때문에 이것은 매우 어렵습니다. 동료들과 좋은 관계를 유지하고 싶은데, 동료나 관리자에게 규정으로 머리를 때릴 때 그들은 이런 일을 하는 사람들에 대해 상반된 감정을 가질 수 있습니다.

이러한 모든 사항 외에도 또 다른 중요한 사항이 있습니다. 즉, 특정 사람이 각 특정 서비스, 배포 절차의 각 특정 섹션을 담당해야 한다는 것입니다. 사람이 없고 이 모든 문제를 연구하기 위해 다른 사람들을 끌어들여야 할 때, 그것은 어려워집니다.

이 모든 것이 도움이 되지 않았고 귀하의 고아 서비스가 여전히 고아인 경우, 아무도 이를 맡길 원하지 않고 문서가 작성되지 않았으며 이 서비스에 호출된 팀이 아무것도 하기를 거부하는 경우 간단한 방법이 있습니다. 다시 실행하는 것입니다. 모든 것.

즉, 서비스에 대한 요구 사항을 새롭게 받아들이고 이상한 기술 솔루션 없이 더 나은 플랫폼에서 더 나은 새로운 서비스를 작성하는 것입니다. 그리고 당신은 전투에서 그곳으로 이동합니다.

우리가 Yii 1에서 서비스를 하다가 Yii 1에서 잘 쓸 수 있는 개발자가 부족해서 더 이상 개발할 수 없다는 것을 깨닫는 상황이 있었습니다. Symfony XNUMX에서는 모든 개발자가 잘 씁니다. 무엇을 해야 할까요? 우리는 시간을 할당하고, 팀을 할당하고, 관리자를 할당하고, 프로젝트를 다시 작성하고 원활하게 트래픽을 전환했습니다.

그 후에는 이전 서비스를 삭제할 수 있습니다. 이것은 구성 관리 시스템에서 일부 서비스를 가져와서 정리한 다음 생산 중인 모든 자동차가 비활성화되어 개발자에게 흔적이 남지 않도록 해야 하는 경우에 제가 가장 좋아하는 절차입니다. 저장소는 Git에 남아 있습니다.

이것이 제가 이야기하고 싶었던 전부이고 토론할 준비가 되었습니다. 주제는 홀리바르이며 많은 사람들이 그 안에서 수영했습니다.

슬라이드에는 언어를 통일했다고 나와 있습니다. 예를 들어 사진의 크기를 조정하는 것이 있었습니다. 꼭 하나의 언어로 엄격하게 제한할 필요가 있나요? PHP에서 이미지 크기 조정은 실제로 Golang에서 수행될 수 있기 때문입니다.

실제로 모든 관행과 마찬가지로 선택 사항입니다. 아마도 어떤 경우에는 바람직하지 않을 수도 있습니다. 하지만 직원이 50명인 회사에 기술 부서가 있다면 그 중 45명은 PHP 전문가이고 또 다른 3명은 Python, Ansible, Puppet 등을 아는 데브옵스이며 그중 한 명만이 일부 글을 쓴다는 점을 이해해야 합니다. 일종의 언어, Go 이미지 크기 조정 서비스를 사용하고 나면 전문 지식도 함께 제공됩니다. 동시에, 특히 드물다면 이 언어를 아는 시장별 개발자를 찾아야 합니다. 즉, 조직적인 관점에서 볼 때 이는 문제가 있습니다. 데브옵스의 관점에서 보면 서비스를 배포하는 데 사용하는 미리 만들어진 플레이북 세트를 복제할 필요가 없을 뿐만 아니라 이를 모두 다시 작성해야 합니다.

우리는 현재 Node.js에 서비스를 구축하고 있으며 이는 별도의 언어를 사용하는 각 개발자를 위한 가까운 플랫폼일 뿐입니다. 그러나 우리는 앉아서 게임이 그만한 가치가 있다고 생각했습니다. 즉, 이것은 당신이 앉아서 생각해야 할 질문입니다.

서비스를 어떻게 모니터링합니까? 로그를 어떻게 수집하고 모니터링하나요?

Elasticsearch에서 로그를 수집하여 Kibana에 넣고, 프로덕션 환경인지 테스트 환경인지에 따라 그곳에서 서로 다른 수집기를 사용합니다. Lumberjack 어딘가, 다른 곳은 기억이 나지 않습니다. 그리고 특정 서비스에는 여전히 Telegraf를 설치하고 다른 곳에서 별도로 촬영하는 곳이 있습니다.

Puppet과 Ansible을 같은 환경에서 어떻게 살 수 있나요?

실제로 이제 우리에게는 두 가지 환경이 있습니다. 하나는 Puppet이고 다른 하나는 Ansible입니다. 우리는 그것들을 혼성화하기 위해 노력하고 있습니다. Ansible은 초기 설정을 위한 좋은 프레임워크이고 Puppet은 플랫폼에서 직접 실습 작업이 필요하며 Puppet은 구성 수렴을 보장하므로 초기 설정을 위한 나쁜 프레임워크입니다. 이는 플랫폼이 자체적으로 최신 상태를 유지하고, 안정화된 머신을 최신 상태로 유지하려면 일정 빈도로 항상 플레이북을 실행해야 함을 의미합니다. 그게 차이점이에요.

호환성을 어떻게 유지하나요? Ansible과 Puppet 모두에 구성이 있습니까?

이것이 우리의 큰 고통입니다. 우리는 손과의 호환성을 유지하고 지금 이 모든 것에서 벗어나는 방법에 대해 생각합니다. Puppet은 패키지를 출시하고 거기에서 일부 링크를 유지하며, 예를 들어 Ansible은 코드를 출시하고 거기에서 최신 애플리케이션 구성을 조정하는 것으로 나타났습니다.

프레젠테이션은 다양한 버전의 Ruby에 관한 것이었습니다. 어떤 해결책이 있나요?

우리는 이것을 한 곳에서 접했고, 그것을 항상 머릿속에 간직해야 합니다. 우리는 Ruby에서 실행되는 애플리케이션과 호환되지 않는 부분을 끄고 별도로 유지했습니다.

올해 컨퍼런스 DevOpsDays 모스크바 7월 11일 Technopolis에서 개최됩니다. XNUMX월 XNUMX일까지 보고서 신청을 받고 있습니다. Напишите 당신이 말하고 싶다면 우리에게.

참가자 등록이 시작되었습니다. 참여하세요!

출처 : habr.com