Linux의 .NET Core, 말을 탄 DevOps

우리는 최선을 다해 DevOps를 개발했습니다. 우리는 8명이었고 Vasya는 Windows에서 가장 멋진 사람이었습니다. 갑자기 Vasya가 떠났고 저는 Windows 개발에서 제공하는 새 프로젝트를 시작하는 임무를 맡았습니다. Windows 개발 스택 전체를 테이블 위에 내려놓았을 때 상황이 고통스럽다는 것을 깨달았습니다...

이야기는 이렇게 시작된다 알렉산드라 신치노바 에 DevOpsConf. 선도적인 Windows 전문가가 회사를 떠났을 때 Alexander는 이제 무엇을 해야 할지 고민했습니다. 물론 Linux로 전환하세요! Alexander는 100명의 최종 사용자를 위한 완성된 프로젝트의 예를 사용하여 어떻게 선례를 만들고 Windows 개발의 일부를 Linux로 이전했는지 알려줄 것입니다.

TFS, Puppet, Linux .NET 코어를 사용하여 프로젝트를 RPM에 쉽고 쉽게 전달하는 방법은 무엇입니까? 개발 팀이 Postgres 및 Flyway라는 단어를 처음 듣고 마감일이 내일 모레인 경우 프로젝트 데이터베이스 버전 관리를 어떻게 지원합니까? Docker와 어떻게 통합하나요? .NET 개발자가 Windows와 스무디를 버리고 Puppet과 Linux를 선택하도록 동기를 부여하는 방법은 무엇입니까? Windows를 프로덕션 환경에서 유지할 힘도, 욕구도, 자원도 없는 경우 이념적 갈등을 어떻게 해결합니까? 이에 대한 내용은 물론 웹 배포, 테스트, CI, 기존 프로젝트에서 TFS를 사용하는 방법, 그리고 물론 Alexander의 보고서 기록에는 부러진 목발 및 작업 솔루션에 대한 정보도 포함되어 있습니다.

그래서 Vasya는 떠났고 작업은 나에게 달려 있으며 개발자는 갈퀴를 들고 초조하게 기다리고 있습니다. 마침내 Vasya를 돌려받을 수 없다는 것을 깨달았을 때 나는 사업을 시작했습니다. 우선 우리 회사의 Win VM 비율을 평가했습니다. 점수는 Windows에 유리하지 않았습니다.

DevOps를 적극적으로 개발하고 있기 때문에 새로운 애플리케이션을 제공하는 접근 방식에 변화가 필요하다는 것을 깨달았습니다. 해결책은 하나뿐이었습니다. 가능하다면 모든 것을 Linux로 옮기는 것입니다. Google이 저를 도와주었습니다. 당시에는 .Net이 이미 Linux로 포팅되어 있었고 이것이 해결책이라는 것을 깨달았습니다!

Linux와 함께 .NET Core를 사용해야 하는 이유는 무엇입니까?

여기에는 몇 가지 이유가 있었습니다. "돈을 지불한다"와 "지불하지 않는다" 사이에서 대다수는 나처럼 두 번째를 선택할 것이다. MSDB 라이선스 비용은 약 1달러이고, Windows 가상 머신 전체를 유지 관리하는 데는 수백 달러가 소요됩니다. 대기업의 경우 이는 큰 비용입니다. 그렇기 때문에 저금 - 첫 번째 이유. 가장 중요한 것은 아니지만 중요한 것 중 하나입니다.

Windows 가상 머신은 Linux 형제보다 더 많은 리소스를 차지합니다. 그들은 무겁다. 대기업의 규모를 고려하여 우리는 Linux를 선택했습니다.

시스템은 기존 CI에 간단히 통합됩니다.. 우리는 진보적인 DevOps라고 생각하며 Bamboo, Jenkins 및 GitLab CI를 사용하므로 대부분의 작업이 Linux에서 실행됩니다.

마지막 이유는 편리한 반주. 우리는 기술적인 부분을 이해하고 중단 없는 서비스를 보장하며 XNUMX차 라인에서 서비스를 유지하는 "에스코트"에 대한 진입 장벽을 낮춰야 했습니다. 그들은 이미 Linux 스택에 익숙했기 때문에 Windows 플랫폼용 소프트웨어의 동일한 기능을 이해하기 위해 추가 리소스를 소비하는 것보다 새로운 제품을 이해하고 지원하고 유지 관리하는 것이 훨씬 쉽습니다.

요구 사항

맨 먼저 - 개발자를 위한 새로운 솔루션의 편의성. 특히 Linux라는 단어가 언급된 이후에는 그들 모두가 변화할 준비가 되어 있지 않았습니다. 개발자는 어셈블리 및 스무디에 대한 자동 테스트 기능이 있는 자신이 선호하는 Visual Studio인 TFS를 원합니다. 생산에 어떻게 전달되는지는 그들에게 중요하지 않습니다. 따라서 우리는 일반적인 프로세스를 변경하지 않고 Windows 개발을 위해 모든 것을 변경하지 않기로 결정했습니다.

새로운 프로젝트가 필요함 기존 CI에 통합. 레일은 이미 거기에 있었고 모든 작업은 구성 관리 시스템의 매개변수, 승인된 전달 표준 및 모니터링 시스템을 고려하여 수행되어야 했습니다.

지원 및 운영의 용이성, 다양한 부서 및 지원 부서의 모든 신규 참가자에 대한 최소 진입 임계값에 대한 조건입니다.

마감일 - 어제.

윈개발그룹

당시 Windows 팀은 어떤 작업을 하고 있었나요?

이제는 자신있게 말할 수 있어요 아이덴티티서버4 유사한 기능을 갖춘 ADFS의 멋진 무료 대안입니다. Entity Framework 코어 - SQL 스크립트를 작성할 필요 없이 OOP 용어로 데이터베이스의 쿼리를 설명할 수 있는 개발자를 위한 천국입니다. 그런데 실행 계획을 논의하는 동안 저는 이 스택을 마치 PostgreSQL과 Git만 인식하는 수메르 설형 문자처럼 보았습니다.

당시 우리는 적극적으로 사용하고 있었습니다. 인형 구성 관리 시스템으로. 대부분의 프로젝트에서 우리는 깃랩 CI, 탄력있는, 균형 잡힌 고부하 서비스를 사용하여 HAProxy 모든 것을 모니터링했습니다 자 비츠, 인대 그라 파나 и 프로 메테우스, 사냥꾼, 그리고 이 모든 것이 철 조각 위에서 회전하고 있었습니다 HP c ESXi 에 VM웨어. 모두가 그것을 알고 있습니다 - 장르의 고전입니다.

우리가 이 모든 개입을 시작하기 전에 무슨 일이 일어났는지 살펴보고 이해하려고 노력합시다.

무엇

TFS는 개발자의 코드를 최종 생산 시스템에 전달할 뿐만 아니라 크로스 플랫폼 수준에서 CI를 제공하기 위해 다양한 서비스와 매우 유연하게 통합할 수 있는 세트를 갖춘 상당히 강력한 시스템입니다.

이전에는 단단한 창이었습니다. TFS는 많은 프로젝트를 조합하는 데 사용된 여러 빌드 에이전트를 사용했습니다. 각 에이전트에는 작업을 병렬화하고 프로세스를 최적화하기 위한 3~4명의 작업자가 있습니다. 그런 다음 릴리스 계획에 따라 TFS는 갓 구운 빌드를 Windows 애플리케이션 서버에 전달했습니다.

우리는 무엇을 달성하고 싶었나요?

우리는 전달 및 개발을 위해 TFS를 사용하고 Linux 애플리케이션 서버에서 애플리케이션을 실행하는데, 그 사이에는 일종의 마법이 있습니다. 이것 마술 상자 그리고 앞에는 일의 소금이 있습니다. 분해하기 전에 한 걸음 물러서서 응용 프로그램에 대해 몇 마디 말씀 드리겠습니다.

계획

이 애플리케이션은 선불카드 처리 기능을 제공합니다.

Client

사용자에는 두 가지 유형이 있었습니다. 처음으로 SSL SHA-2 인증서를 사용하여 로그인하여 액세스 권한을 얻었습니다. 유 초 로그인과 비밀번호를 사용하여 액세스했습니다.

HAProxy

그런 다음 클라이언트 요청이 HAProxy로 이동하여 다음 문제를 해결했습니다.

• 기본 승인;
• SSL 종료;
• HTTP 요청 튜닝
• 방송 요청.

클라이언트 인증서가 체인을 따라 확인되었습니다. 우리 - 권위 우리는 고객에게 서비스를 제공하기 위해 인증서를 직접 발급하기 때문에 이를 감당할 수 있습니다.

세 번째 사항에 주목하세요. 잠시 후에 다시 설명하겠습니다.

백엔드

그들은 Linux에서 백엔드를 만들 계획이었습니다. 백엔드는 데이터베이스와 상호 작용하고 필요한 권한 목록을 로드한 다음 승인된 사용자가 가진 권한에 따라 금융 문서에 서명하고 실행을 위해 전송하거나 일종의 보고서를 생성할 수 있는 액세스 권한을 제공합니다.

HAProxy를 통한 비용 절감

각 클라이언트가 탐색한 두 가지 컨텍스트 외에도 ID 컨텍스트도 있었습니다. 아이덴티티서버4 로그인만 하면 됩니다. 이것은 무료이며 강력한 아날로그 기능입니다. ADFS - Active Directory Federation Services.

신원 요청은 여러 단계로 처리되었습니다. 첫 번째 단계 - 클라이언트 백엔드에 들어갔다, 이 서버와 통신하고 클라이언트에 대한 토큰이 있는지 확인했습니다. 찾을 수 없는 경우 요청은 원래 컨텍스트로 다시 반환되었지만 리디렉션을 사용하고 리디렉션을 통해 ID로 이동했습니다.

두 번째 단계 - 요청이 수신되었습니다. IdentityServer의 인증 페이지로 이동합니다. 클라이언트가 등록된 위치와 오랫동안 기다려온 토큰이 IdentityServer 데이터베이스에 나타났습니다.

세 번째 단계 - 클라이언트가 다시 리디렉션되었습니다 그것이 나온 맥락에.

IdentityServer4에는 다음과 같은 기능이 있습니다. HTTP를 통해 반환 요청에 대한 응답을 반환합니다.. 서버를 설정하는 데 아무리 어려움을 겪었더라도, 설명서를 통해 아무리 깨달았더라도 HTTPS를 통해 제공된 URL이 포함된 초기 클라이언트 요청을 받을 때마다 IdentityServer는 동일한 컨텍스트를 HTTP로 반환했습니다. 우리는 충격을 받았습니다! 그리고 우리는 이 모든 것을 ID 컨텍스트를 통해 HAProxy로 전송했고, 헤더에서 HTTP 프로토콜을 HTTPS로 수정해야 했습니다.

개선된 점은 무엇이며 저장한 곳은 어디입니까?

IdentityServer4를 별도의 세그먼트에 별도의 노드로 배치하지 않고 애플리케이션의 백엔드가 실행되는 동일한 서버의 백엔드와 함께 사용했기 때문에 사용자, 리소스 그룹을 인증하기 위한 무료 솔루션을 사용하여 비용을 절약했습니다. .

작동 방식

약속대로 Magic Box입니다. 우리는 Linux로 전환할 것이 보장된다는 것을 이미 알고 있습니다. 솔루션이 필요한 특정 작업을 공식화해 보겠습니다.

인형극이 등장합니다. 서비스와 애플리케이션 구성을 제공하고 관리하려면 멋진 레시피를 작성해야 했습니다. 연필 한 통은 작업이 얼마나 빠르고 효율적으로 수행되었는지를 설득력 있게 보여줍니다.

배달 방법. 기준은 RPM입니다. Linux에서는 그것 없이는 할 수 없다는 것을 모두가 이해하지만 어셈블리 후 프로젝트 자체는 실행 가능한 DLL 파일 세트였습니다. 그 중 약 150 개가 있었는데 프로젝트가 상당히 어려웠습니다. 유일한 조화로운 솔루션은 이 바이너리를 RPM으로 패키징하고 여기에서 애플리케이션을 배포하는 것입니다.

버전 관리. 출시를 자주 해야 했고, 패키지 이름을 어떻게 구성할지 결정해야 했습니다. TFS와의 통합 수준에 대한 질문입니다. Linux에 빌드 에이전트가 있었습니다. TFS가 작업을 처리기(작업자)에게 빌드 에이전트로 보낼 때 처리기 프로세스 환경에서 끝나는 여러 변수도 전달합니다. 이러한 환경 변수에는 빌드 이름, 버전 이름 및 기타 변수가 포함됩니다. 이에 대한 자세한 내용은 "RPM 패키지 구축" 섹션을 참조하세요.

TFS 설정 파이프라인 설정에 들어갔습니다. 이전에는 Windows 에이전트에서 모든 Windows 프로젝트를 수집했지만 이제 Linux 에이전트가 나타납니다. 빌드 그룹에 포함되어야 하고 일부 아티팩트로 보강되며 이 빌드 에이전트에 어떤 유형의 프로젝트가 빌드될 것인지 알려주는 빌드 에이전트입니다. , 어떻게든 파이프라인을 수정합니다.

IdentityServer. ADFS는 우리 방식이 아니며 오픈 소스를 지향합니다.

구성요소를 살펴보겠습니다.

마술 상자

네 부분으로 구성됩니다.

Linux 빌드 에이전트. Linux는 Linux용으로 제작되었기 때문에 논리적입니다. 이 부분은 세 단계로 이루어졌습니다.

• 작업자 구성 프로젝트에 대한 분산 작업이 예상되었기 때문에 혼자가 아닙니다.
• .NET Core 1.x 설치. 표준 저장소에서 이미 1을 사용할 수 있는데 왜 2.0.x를 사용해야 합니까? 왜냐하면 우리가 개발을 시작했을 때 안정 버전이 1.09였고, 이를 기반으로 프로젝트를 만들기로 결정했기 때문입니다.
• 힘내 2.x.

RPM 저장소. RPM 패키지를 어딘가에 저장해야 했습니다. 모든 Linux 호스트에서 사용할 수 있는 동일한 회사 RPM 저장소를 사용한다고 가정했습니다. 그것이 그들이 한 일입니다. 저장소 서버가 구성되었습니다. 웹 후크 지정된 위치에서 필요한 RPM 패키지를 다운로드했습니다. 패키지 버전이 빌드 ​​에이전트에 의해 웹훅에 보고되었습니다.

깃랩. 주목! 여기서 GitLab은 개발자가 아닌 운영 부서에서 애플리케이션 버전, 패키지 버전을 제어하고 모든 Linux 시스템의 상태를 모니터링하며 레시피(모든 Puppet 매니페스트)를 저장하는 데 사용됩니다.

인형 — 논쟁의 여지가 있는 모든 문제를 해결하고 Gitlab에서 원하는 구성을 정확하게 제공합니다.

우리는 다이빙을 시작합니다. RPM으로의 DLL 전달은 어떻게 작동합니까?

DDL을 RPM으로 전달

.NET 개발의 인기 스타가 있다고 가정해 보겠습니다. Visual Studio를 사용하고 릴리스 분기를 만듭니다. 그 후 Git에 업로드하는데 여기서 Git은 TFS 엔터티, 즉 개발자가 작업하는 애플리케이션 저장소입니다.

그 후 TFS는 새로운 커밋이 도착했음을 확인합니다. 어떤 앱인가요? TFS 설정에는 특정 빌드 에이전트에 어떤 리소스가 있는지 나타내는 레이블이 있습니다. 이 경우 그는 우리가 .NET Core 프로젝트를 빌드하고 있는 것을 확인하고 풀에서 Linux 빌드 에이전트를 선택합니다.

빌드 에이전트는 소스를 수신하고 필요한 것을 다운로드합니다. 의존성 .NET 저장소, npm 등에서 애플리케이션 자체를 빌드하고 후속 패키징을 한 후 RPM 패키지를 RPM 저장소로 보냅니다.

반면에 다음과 같은 일이 발생합니다. 운영 부서 엔지니어는 프로젝트 출시에 직접 참여합니다. 그는 패키지 버전을 변경합니다. 히에라 애플리케이션 레시피가 저장된 저장소에서 Puppet이 트리거됩니다. 얌, 저장소에서 새 패키지를 가져오면 새 버전의 애플리케이션을 사용할 준비가 됩니다.

말로 하면 모든 것이 간단하지만 빌드 에이전트 자체 내부에서는 어떤 일이 발생할까요?

패키징 DLL RPM

TFS로부터 프로젝트 소스 및 빌드 작업을 받았습니다. 빌드 에이전트 소스에서 프로젝트 자체를 구축하기 시작합니다.. 조립된 프로젝트는 세트로 제공됩니다. DLL 파일, 파일 시스템의 부하를 줄이기 위해 zip 아카이브로 패키지됩니다.

ZIP 아카이브는 폐기됩니다. RPM 패키지 빌드 디렉터리로 이동합니다. 다음으로 Bash 스크립트는 환경 변수를 초기화하고 빌드 버전, 프로젝트 버전, 빌드 디렉터리 경로를 찾고 RPM-build를 실행합니다. 빌드가 완료되면 패키지가 다음 위치에 게시됩니다. 로컬 저장소, 빌드 에이전트에 있습니다.

다음으로 빌드 에이전트에서 RPM 저장소의 서버로 JSON 요청이 전송되었습니다. 버전 및 빌드 이름을 나타냅니다. 앞서 이야기한 Webhook은 빌드 에이전트의 로컬 저장소에서 바로 이 패키지를 다운로드하고 새 어셈블리를 설치할 수 있도록 만듭니다.

RPM 저장소에 이 특정 패키지 전달 체계가 있는 이유는 무엇입니까? 어셈블된 패키지를 저장소로 즉시 보낼 수 없는 이유는 무엇입니까? 사실 이는 안전을 보장하기 위한 조건이다. 이 시나리오는 권한이 없는 사람이 모든 Linux 시스템에 액세스할 수 있는 서버에 RPM 패키지를 업로드할 가능성을 제한합니다.

데이터베이스 버전 관리

개발팀과의 협의에서 그 사람들은 MS SQL에 더 가깝다는 것이 밝혀졌지만 Windows가 아닌 대부분의 프로젝트에서는 이미 PostgreSQL을 온 힘을 다해 사용하고 있었습니다. 우리는 이미 유료 모든 것을 포기하기로 결정했기 때문에 여기서도 PostgreSQL을 사용하기 시작했습니다.

이 부분에서는 데이터베이스 버전을 관리하는 방법과 Flyway와 Entity Framework Core 중에서 선택하는 방법을 설명하고 싶습니다. 그들의 장점과 단점을 살펴보겠습니다.

죄수 팀은

이동 경로는 한 방향으로만 갑니다. 우리는 되돌릴 수 없어 - 이것은 상당한 단점입니다. 개발자 편의성 측면에서 다른 방법으로 Entity Framework Core와 비교할 수 있습니다. 우리는 이것을 최우선으로 삼았고 주요 기준은 Windows 개발을 위해 아무것도 변경하지 않는 것이었습니다.

Flyway를 위해 어떤 종류의 포장지가 필요했습니다남자들이 글을 쓰지 않도록 SQL 쿼리. OOP 용어로 작동하는 데 훨씬 더 가깝습니다. 우리는 데이터베이스 개체 작업에 대한 지침을 작성하고 SQL 쿼리를 생성하여 실행했습니다. 데이터베이스의 새 버전이 준비되고 테스트되었습니다. 모든 것이 정상이고 모든 것이 작동합니다.

Entity Framework Core에는 마이너스가 있습니다. 부하가 심한 경우 최적이 아닌 SQL 쿼리를 작성합니다., 그리고 데이터베이스의 감소가 상당할 수 있습니다. 하지만 우리는 고부하 서비스가 없기 때문에 수백 RPS 단위로 부하를 계산하지 않고 이러한 위험을 감수하고 문제를 미래의 우리에게 위임했습니다.

프로

Entity Framework 코어 즉시 사용 가능하며 개발이 쉽습니다.및 플라이웨이 기존 CI에 쉽게 통합. 하지만 우리는 개발자에게 편리함을 제공합니다 :)

롤업 절차

Puppet은 마이그레이션을 담당하는 버전을 포함하여 패키지 버전이 변경될 것임을 확인합니다. 먼저 마이그레이션 스크립트와 데이터베이스 관련 기능이 포함된 패키지를 설치합니다. 그런 다음 데이터베이스와 함께 작동하는 애플리케이션이 다시 시작됩니다. 다음으로 나머지 구성 요소를 설치합니다. 패키지가 설치되고 애플리케이션이 시작되는 순서는 Puppet 매니페스트에 설명되어 있습니다.

애플리케이션은 토큰, 데이터베이스 비밀번호와 같은 민감한 데이터를 사용하며, 이 모든 데이터는 Puppet 마스터의 구성으로 가져와서 암호화된 형식으로 저장됩니다.

TFS 문제

모든 것이 실제로 우리에게 적합하다는 것을 결정하고 깨달은 후, 저는 다른 프로젝트에서 Win 개발 부서 전체를 위해 TFS의 어셈블리에 무슨 일이 일어나고 있는지 살펴보기로 결정했습니다. 우리가 빠르게 구축/릴리스하고 있는지 여부에 관계없이, 속도에 심각한 문제가 있음을 발견했습니다.

주요 프로젝트 중 하나를 조립하는 데 12~15분이 소요됩니다. 너무 긴 시간이므로 그렇게 살 수는 없습니다. 빠른 분석에 따르면 I/O가 크게 감소한 것으로 나타났으며 이는 어레이에서 발생했습니다.

구성요소별로 분석한 결과 세 가지 초점을 확인했습니다. 첫 번째 - "카스퍼스키 백신", 모든 Windows 빌드 에이전트의 소스를 검색합니다. 두번째 - Windows 인덱서. 비활성화되지 않았으며 배포 프로세스 중에 빌드 에이전트에서 모든 것이 실시간으로 인덱싱되었습니다.

세 번째 - Npm 설치. 대부분의 파이프라인에서 우리는 이 정확한 시나리오를 사용한 것으로 나타났습니다. 그 사람은 왜 나쁜가요? Npm 설치 절차는 종속성 트리가 형성될 때 실행됩니다. 패키지 잠금.json, 프로젝트를 빌드하는 데 사용되는 패키지 버전이 기록됩니다. 단점은 Npm 설치가 매번 인터넷에서 최신 버전의 패키지를 가져오고 대규모 프로젝트의 경우 시간이 많이 걸린다는 것입니다.

개발자는 때때로 특정 부분이나 전체 프로젝트가 어떻게 작동하는지 테스트하기 위해 로컬 컴퓨터에서 실험합니다. 때로는 모든 것이 현지에서 멋지다는 것이 밝혀졌지만 조립하고 출시했지만 아무것도 작동하지 않았습니다. 우리는 문제가 무엇인지 파악하기 시작합니다. 예, 종속성이 있는 다양한 버전의 패키지입니다.

결정

• AV 예외의 소스.
• 인덱싱을 비활성화합니다.
• 이동 npm ci.

npm ci의 장점은 다음과 같습니다. 종속성 트리를 한 번 수집합니다., 그리고 우리는 개발자에게 제공할 기회를 얻습니다 현재 패키지 목록, 원하는 만큼 현지에서 실험할 수 있습니다. 이것 시간 절약 코드를 작성하는 개발자.

구성

이제 저장소 구성에 대해 조금 설명합니다. 역사적으로 우리는 Nexus 다음을 포함한 리포지토리 관리용 내부 REPO. 이 내부 저장소에는 자체 작성 모니터링과 같은 내부 목적으로 사용하는 모든 구성 요소가 포함되어 있습니다.

우리는 또한 사용합니다 NuGet, 다른 패키지 관리자에 비해 캐싱이 더 좋기 때문입니다.

결과

빌드 에이전트를 최적화한 후 평균 빌드 시간이 12분에서 7분으로 단축되었습니다.

Windows용으로 사용할 수 있었지만 이 프로젝트에서 Linux로 전환한 모든 컴퓨터를 계산하면 약 $10를 절약할 수 있습니다. 이는 라이센스 비용만 절약한 금액이고 콘텐츠를 고려하면 그 이상입니다.

계획

다음 분기에는 코드 전달 최적화 작업을 계획했습니다.

사전 빌드된 Docker 이미지로 전환. TFS는 Docker 이미지의 트리거 기반 어셈블리를 포함하여 파이프라인에 통합할 수 있는 많은 플러그인이 포함된 멋진 기능입니다. 우리는 동일한 트리거에 대해 이 트리거를 만들고 싶습니다. 패키지 잠금.json. 프로젝트를 빌드하는 데 사용되는 구성 요소의 구성이 어떻게든 변경되면 새 Docker 이미지를 빌드합니다. 나중에 조립된 애플리케이션과 함께 컨테이너를 배포하는 데 사용됩니다. 지금은 그렇지 않지만, 우리 회사에서 활발히 개발 중이고 오랫동안 프로덕션 솔루션을 제공해 온 쿠버네티스에서 마이크로서비스 아키텍처로 전환할 예정이다.

개요

나는 모두에게 윈도우를 버리라고 권유하지만, 요리하는 방법을 몰라서가 아니다. 그 이유는 대부분의 오픈소스 솔루션이 리눅스 스택. 괜찮으세요 자원을 절약하다. 제 생각에는 미래는 강력한 커뮤니티를 갖춘 Linux 기반 오픈 소스 솔루션에 달려 있습니다.

Alexander Sinchinov의 연사 프로필 GitHub에서.

DevOps 회의 전문가에 의한 전문가를 위한 개발, 테스트, 운영 프로세스의 통합에 관한 컨퍼런스입니다. 그래서 알렉산더가 말한 프로젝트는 무엇입니까? 구현되어 작동 중이며 공연 당일 두 번의 성공적인 릴리스가 있었습니다. ~에 RIT++의 DevOps 컨퍼런스 27월 28일과 XNUMX일에는 실무자들에게서 비슷한 사례가 더 많이 나올 예정이다. 마지막 객차에 탑승할 수 있으며 레포트를 제출하다 아니면 시간을 갖고 예약하다 티켓. Skolkovo에서 만나보세요!

출처 : habr.com