가상 머신을 사용한 개발에 대한 생각

저는 스타트 업의 개발 책임자로 일할 것이며 개발에 VM을 사용할 것을 제안했습니다. 테스트 / 개발을 위해 VM이있는 데스크톱이있는 각 개발자에 대해 이야기하는 것이 아닙니다. 모든 VM이 관리되는 서버 랙이 있고 개발자가 로컬 또는 집에서 원격으로 마이크로 PC (ChromeOS 사람?) 컴퓨터.

나에게 이점은 장기적으로 확장 성이 뛰어나고 저렴하고 관리하기 쉬우 며 하드웨어를 최대한 활용할 수 있다는 것입니다. 단점에 관해서는, 나는 우리가 상기 설정을 설정 / 유지하기 위해 누군가가 필요하다는 것 이외의 특정 쇼탑을 생각할 수 없습니다.

나는 당신의 일부가 당신의 직장에서 비슷한 설정을하고 당신의 의견에 무게를 둘 수 있기를 바랐습니다. 감사.

개발 예산의 일부로 절약하고자하는 것은 무엇입니까? 엡실론이 걱정되는 것 같습니다. 개발자를위한 기계 비용은 개발자를 직원으로 유지하는 데 드는 총 비용의 5 % 미만입니다. 따라서 중요한 질문은 "개발자 시간을 절약 할 것인가?"입니다. 개발 소프트웨어를 설치하고 업그레이드하는 데 시간을 소비하지 않아도 될 수 있습니다. 또는 네트워크가 다운되거나 서버가 다운되거나 네트워크 전체의 응답 성이 가장 적은 경우 시간이 소요될 수 있습니다. 최신 개발은 IDE 또는 키가 매우 지능적인 편집기와의 키 스트로크 별 상호 작용에 달려 있습니다. 이러한 상호 작용을 수십 밀리 초까지 지연 시키면 개발자의 생산성이 떨어집니다. 개발자가이 새로운 작업 방식을 배우는 비용도 있습니다.

이들은 VM에 대한 이의 제기가 아니라 원격 개발에 대한 이의 제기입니다.

나는 당신이 페니와 어리석은 짓이라고 생각합니다.

우선, 기계 비용은 개발자 비용과 비교하여 사소 합니다. 기계 비용을 최소화하지 말고 생산성을 극대화해야합니다.

둘째, 대기 시간 (대역폭 아님)은 많은 프로그래밍 작업, 특히 텍스트 편집의 핵심입니다. 개발자를 위해 컴퓨터에 1 달러 / 파운드 / 유로를 절약 할 때마다 최소한 10 개의 네트워크 업그레이드를 사용하여 생산성을 똑같이 유지하고 심지어는 공급을 통해 절약하면 생산성이 향상 될 것입니다 당신은 어딘가에 쓰레기통에서 발견 된 펜티엄 III을 가지고 있습니다.

또한 개발자가 대상 최종 사용자에게 기대되는 환경과 적어도 합리적으로 가까운 환경을 사용하는 데 상당한 이점이 있다고 생각합니다. 스펙과 같은 공식적인 성능 목표에 관계없이, 대부분의 프로그래머는 코드를 테스트 할 때 코드가 어떻게 "느껴지는"지를 기반으로합니다. 최종 사용자와 완전히 다른 환경을 사용하는 경우 사소한 문제에 시간을 낭비하면서 주요 문제를 완전히 간과 할 수 있습니다.

지원 등의 관점에서 균질 한 환경이 매력적이기 때문에 일반적으로 가능한 한 많은 개발자 머신을 권장해야합니다. 어쨌든 개발자는 많은 지원을 거의 필요로하지 않으며 최소한의 투자 비용을 상환하는 것보다 다른 그래픽 칩, CPU, 네트워크 어댑터 등으로 실패 할 코드가있을 때 즉시 알 필요가 없습니다.

결론 : 가상화 된 서버 환경에서 사용 하도록 의도 된 코드를 작성하는 경우 개발자에게 제공해야합니다. 어쨌든 테스트를 위해 노력하고 있다면 개발에도 의미가 있습니다 (그러나 반드시 그런 것은 아닙니다). 어쨌든 심한 오버 speced 서버 및 네트워크를 필요로 (또는 적어도이) 경우 마찬가지로, 그것은 수도 당신이 이미 가지고있는 사용하여 해당 활용하는 것이합니다.

그러나 가장 일반적인 상황에서는 이것이 해결하는 것보다 더 많은 문제가 발생할 가능성이 높습니다.

그것은 필자의 아이디어 중 하나였습니다. 필요한 소프트웨어를 모두 갖춘 고성능 서버와 원격 데스크톱을 통해 서버에 연결하는 데만 사용되는 저 성능 데스크탑 PC가 많이 있습니다.

이점은 다음과 같습니다.

• 확실한 백업. 일부 개발자는 데스크톱 컴퓨터를 정기적으로 백업하고 싶지 않을 수 있으므로 중앙 솔루션이 더 안정적입니다.
• 모든 개발자가 어디서나 작업 할 수있는 가능성. 이것은 회사의 모든 PC에서 일하는 것을 의미합니다. 아침에 개발자가 조용한 작업 조건을 원한다고 가정 해 봅시다. 그는 자신의 방으로 가서 그곳에서 일합니다. 그런 다음 그는 페어 프로그래밍을하거나보다 사회적인 환경에서 일하기를 원합니다. 그는 데스크탑 PC를 종료하고 10 대의 컴퓨터가있는 다른 방으로 가서 연결합니다. 아니요 "모든 앱을 다시로드해야합니다".

글쎄, 그것에 몇 가지 심각한 문제가있어서, 나는 내년에 이와 같은 것을 결코 사용하지 않을 것이라고 생각합니다.

• 원격 솔루션의 특이성. 한 번에 여러 대의 컴퓨터 화면을 사용하여 멀리 떨어져 작업하는 것은 어떻습니까? 쉬운가요? 명백한가요? 먼 거리에서 작업 할 때 매일 사용하는 바로 가기를 사용할 수 있습니까? 확실하지 않아요. 현재 실행중인 프로그램 목록을 보려면 Ctrl + Shift + Esc를 누르면 어떻게됩니까? 예, 작동하지 않습니다. 이제 다른 방식으로 수행하는 것을 기억해야합니다.

• 성능이 저하되었습니다. 성능 저하가 전혀 없을지 확실하지 않습니다. 그리고 느린 컴퓨터를 사용하는 프로그래머는 불행한 프로그래머라는 것을 기억하십시오. 그리고 프로그래머가 까다로운 조건에 만족하지 못하게 만드는 회사는 고품질 소프트웨어를 생산하지 않습니다.

• 재해의 더 큰 영향. 중복 서버에서 솔루션을 호스팅 하시겠습니까? 회사에 중복 네트워크가 있습니까? 라우터가 다운되고 중복되지 않는다고 가정 해 봅시다. 이제 모든 개발자가 작업 할 수 없습니다. 조금도. 소프트웨어가 로컬에 설치되어 있지 않기 때문입니다. 소스 코드조차 없기 때문에 서버에 있습니다. 따라서 모든 사람이 멈추고 라우터 교체를 기다리기 위해 시간당 모든 사람에게 돈을 지불하고 있습니다.

• 하드웨어 비용. 하나의 서버 인 경우 비용은 얼마입니까? 예를 들어, 20 명의 개발자라면 서버에 64GB의 RAM이 충분할까요? 확실하지 않습니다. CPU가 2 개인 쿼드 코어 솔루션으로 충분합니까? 다시 한 번, 나는 의심이있다. 그렇지 않으면 어떻게 생각하십니까? 어떤 종류의 구름? 아니면 여러 서버에서 작동하는 확장 가능한 솔루션이 있습니까? 컴퓨터 당 Windows Server (Windows를 사용하는 경우)의 비용을 지불 할 준비가 되셨습니까?

• 전기 비용. 완전히 원격으로 작업하는 경우 로컬에서 작업하는 것처럼 거의 같은 양의 전원 서버 쪽을 사용하고 로컬 시스템과 네트워크에서 낭비하는 전력량을 소비한다는 의미입니다.

• 라이센스. 이점이나 이점으로 사용해야하는지 확실하지 않지만이 경우 소프트웨어 라이센스 비용이 훨씬 더 높아질 것 같습니다.

그리고 관리, 지원, 배포, 유지 관리 비용을 모두 생각해보십시오. 이와 같은 사용자 지정 솔루션을 사용하면 문제가 발생할 때마다 모든 개발자가 NOP를 보지 않고 작업을 계속할 수 있기를 기다리는 것을 고려하지 않고 쉽게 커질 수 있습니다.

온 디맨드 Amazon EC2 인스턴스를 개발자 머신으로 사용합니다. 이것은 비용과 관련이 없습니다. 우리는 여러 프로젝트를 수행하는 "개발자 풀 (pool)"을 보유하고 있으며 프로젝트 간을 신속하게 이동할 수있는 능력이 필요합니다.

일반적으로 VM은 초기 설정 시간을 절약합니다. 그러나 장기적으로는 생산성 손실로 인해 시간이 낭비됩니다. 개발자 비용이 기계 비용보다 훨씬 크기 때문에 비용은 축이 아닙니다.

생산성 비용에는 VM 이미지를 시작하는 데 걸리는 시간 (몇 분), 응답 속도 저하 및 리소스 / 메모리 제약 조건이 포함됩니다. 이것들은 처음에는 많지 않지만 시간이 지남에 따라 성가 시게됩니다.

프로젝트 중 하나에서 코드를 리팩터링하여 초기 설정을 단순화하여 "코드를 다운로드하고 maven을 실행"했습니다. 이 변경으로 인해 새로운 개발자가 프로젝트 작업을 시작하는 것이 간단 해졌으며 이제는 아무도 Amazon VM 이미지를 사용하지 않습니다. 우리는 다른 프로젝트에서도 이것을 모방하려고하지만 시간이 걸릴 것입니다. 그때까지 우리는 ec2 이미지를 가지고 있습니다.

여기서 매우 조심하십시오. 저는 최근 IT 부서의 모든 사람이 본질적으로 같은 이유로 VM을 가지고있는 고객에게 배치되었습니다. 책상에 저가형 PC를 설치 한 다음 VM에 원격으로 연결하고 정상적인 작업을 수행 할 수있게했습니다.

그 경험은 예쁘지 않았습니다. 적어도 일주일에 한 번 우리는 다양한 이유로 매우 느리게 달렸습니다. 일반적으로 팀의 누군가가 프로세서 집약적 인 SSIS 패키지를 언제 실행하고 있는지 알 수 있습니다. 그들은 결국 우리 중 일부를 다른 서버로 옮겨서 일부 서버를 도왔지만 성능은 결코 좋지 않았습니다.

서버 전원, 처리 요구 사항, 서비스 할 시스템 수 등에 대한 실사를 수행하면 돈을 절약 할 수 있지만 제대로 구현하지 않으면 LOTS가 발생할 수 있습니다. 두통.

참고 : 이것은 VM 아키텍처의 불꽃이 아닙니다-그것을보고있는 사람들에게 경고 일뿐입니다. 구현하기 전에 오리가 일렬로 있는지 확인하십시오.

가상 머신 개발은 제대로 수행 될 수 있지만 제대로 수행 된 경우에만 가능합니다.

• VM을 사용하면 개발자 당 한 대가 아닌 팀 전체에 단일 컴퓨터를 사용할 수 있다고해서 좋은 생각이 아닙니다
• 재부팅시 응답 시간이 24 시간 인 지원 티켓을 열지 않아도됩니다.
• 개발 VM은 개발자로부터 5000 마일 떨어진 데이터 센터에 있지 않아야합니다.
• VM이 개발자에 의해 관리되어 지원되지 않을 수 있지만 이것이 소스 제어와 같은 네트워크 서비스에 액세스 할 수 없다는 의미는 아닙니다.
• 따옴표를 움라우트로 입력하는 일부 사용자 지정 "높은 보안"애플릿이 아니라 원격 데스크톱 연결이 표준이어야합니다.
• 새로운 VM을 얻거나 기존 VM을 재 구축하는 데 몇 주가 아닌 몇 분이 소요됩니다.

나는이 모든 문제를 보았고, 특히 그들과 함께 일하는 것을 좋아하지 않는다. 그러나 집에서도 선택적으로 사용하는 VM 설정이 있습니다. 이는 로컬 설치보다 빠르게 실행되며 환경이 불안정 할 때 다른 프로젝트를위한 별도의 환경과 빠른 재 구축과 같은 것들을 허용합니다.

VM으로 작업하지만 기본 프로젝트에는 권장하지 않습니다.

VM을 개발에 사용하는 이유는 레거시 프로젝트 (예 : VB6, .NET 1.1 등)를 지원해야하고 VS2003 / 2005 / vb6 / etc를 설치하여 메인 시스템을 더럽 히고 싶지 않기 때문입니다. ... 그것은 잘 작동하지만 간헐적으로 문제가 있습니다.

또한 상호 작용이 느리고 VM은 시작 / 종료하는 데 시간이 걸리고 Win7의 Aero와 같은 고유 UI 효과가 없습니다.

당신이 돈을 절약하기 위해 무엇이든 당신은 당신의 팀에 부과하려는 번거 로움과 낭비 할 것입니다. 또한 여기에 언급 된 바와 같이 멀티 스크린 지원은 없습니다. 생산성을 높이려면 화면이 3 개 이상 필요합니다.

개발의 첫 번째 규칙은 개발자의 만족을 유지하는 것입니다. 원격 VM과는 거의 불가능하다는 것을 알 수 있습니다. 다중 모니터 지원은 문제가 많고 네트워크 지연과 결함이 번거롭고 일반적으로 비용 절감이 최소화됩니다.

VM에서 작업하십시오. 물론 로컬 VM도 허용하고 실제 컴퓨터도 엄청나게 빠른 짐승으로 만드십시오.

100 % 재택 근무를하고 개인 ISP와 VPN (높은 안정성에도 불구하고)간에 오프라인 모드에서 작업 할 수없는 경우 미끄러짐을 유발할 수있는 미끄러짐이 충분합니다.

나는 일반적으로 다양한 VirtualBox 이미지를 스핀 업하고 그로부터 작동합니다. 유선으로 수백 MB를 복사하는 것도 로컬에서 새로운 것을 필요로한다면 시간이 많이 걸리지 않습니다.

우리 팀은 "느린 PC / 빠른 VM 서버"구성을 성공적으로 구현했습니다. 20 명의 개발자 팀을 위해 파이버를 통해 매우 빠른 SAN에 연결된 8 개의 프로세서, 256GB RAM 서버가있었습니다. 각 개발자에게 비슷한 성능의 워크 스테이션을 제공하는 것보다 비싸지 만 저렴했습니다. 소규모 팀 (4 명의 개발자)에게는 규모의 경제가 시작되어 실제로 어떤 것도 절약 할 수 있을지 모르겠습니다.

개발 용 VM은 살펴볼 가치가 있지만 재정 비용은 잘못된 이유입니다.

이 내용은 NAnt & CruiseControl.net을 사용하는 Marc Holmes의 Expert .NET Delivery 에서 간략하게 다루었 습니다. 즉, VM에서 개발하는 데 대한 주장은 작업의 모든 측면이 개발자의 특정 구성에 의존하지 않도록하는 것입니다. 모든 프로젝트가 시작될 때 VM을 사용하며 실제로 특정 도구가 필요하지 않으면 계속 작동하지 않습니다. 이렇게하면 변경 사항이 다른 사람의 컴퓨터가 아닌 다른 사람의 컴퓨터에서 손상 될 가능성이 최소화됩니다. 개발자들은 장난감을 가지고 다니는 데 울부 짖을 수 있지만 궁극적으로 도구에 대한 의존은 약점이며 깨끗한 환경에서 직관적으로 할 수없는 것은 냄새입니다.

위에서 제시 한 주장을 반드시 믿지 는 않습니다 . 나는 이해하고 어느 정도까지는 그들과 일치하지만 토론을 위해 논쟁을 위해 그들을 만들고 있습니다.

잠재적 인 단점

• VM 호스트가 다운되면 ... 당신이있어 모두 씻어 버렸어요. 20 명으로 구성된 팀이 있다면 "GAH! HOST NOT RESPONDING !?" 일제히 ... 재미 없어요.
• 스냅 샷을 허용하면 리소스를 빨리 소모합니다. 20 명 * 10-20 개의 스냅 샷은 각각 많은 HDD 공간을 확보합니다 (또는 최소한 문제를 일으키기 시작하기에 충분 함).
• 호스트에서 리소스 사용에 문제가 발생하면 모두 가 고통을 경험합니다.

IME는 좋은 솔루션이며 작동하지만 호스트에는 적절한 하드웨어가 필요하며 나쁜 일이 발생하면 모든 사람에게 발생합니다.

이것은 Joel 테스트의 가장 중요한 기준 중 하나에 실패합니다.

모든 개발자가 보유 할 수있는만큼의 RAM이있는 i3 이상의 노트북 또는 데스크탑을 보유하고 있는지 확인합니다.

8GB는 내가 노력하는 것입니다.

생산성을 높이고 서버 유지 관리 비용이 많이 들지 않고 개발 및 테스트를 위해 로컬 컴퓨터에서 실제로 Virtual Box를 실행할 수 있습니다. 가상 박스를 설치하고 다른 브라우저와 설치 프로그램을 테스트 할 수 있으며 모든 것을 "IT"서비스에 연결할 필요없이 알려진 양호한 구성으로 되돌릴 수 있습니다.

개발자는 로컬 컴퓨터에서 RAM과 루트 권한이 가장 많은 회사에서 가장 빠른 컴퓨터가 필요합니다. 이야기의 끝.

로컬 VM (로컬 PC에서 실행)과 원격 VM 모두 개발을 위해 VM에서 작업했습니다. 지역 사람들은 원격 사람들보다 작업하기 가 훨씬 좋았습니다.

RDP로 연결 한 원격 VM은 모든 키 입력과 동작간에 약간의 지연이있었습니다. 이러한 조건 하에서 짧은 시간 동안 개발할 수는 있지만 매일 매일 실망스러워졌습니다.

Linux 시스템에서 Flash Builder를 실행해야했기 때문에 VMWare의 로컬 VM에서 행복하게 개발했으며 메모리가 충분한 한 매우 만족 스러웠습니다.

우리는 원격 컴퓨터를 위해 그렇게하며 상당히 잘 작동합니다. 대부분의 경우 집에서 일하는 경우가 거의 없으며 (일반적으로 여기저기서 긴급 수정을 위해서만), 사무실의 빠른 데스크탑 컴퓨터에 원격으로 연결되는 상당히 저렴한 넷북을 사용합니다. 그들은 여전히 ​​느리게 (아마도 네트워크에 의해 무엇보다 제한적이지만) 때때로 짧은 작업을 위해 일합니다. 그러나 VM은 종종 최고의 하드웨어 IMHO로도 약간 혼란스러워 약간의 지연을 유발할 수 있기 때문에 풀 타임 작업에는 적합하지 않습니다.

마지막 직장에서 우리는 정확히 다음을 수행했습니다.

모든 개발자가 계정을 가지고있는 Windows 터미널 서버를 사용했습니다. 개발자는 여전히 일반 PC를 가지고 있었지만 (이미 존재했기 때문에) PC는 RDP 클라이언트 만 실행했습니다.

Java 개발을 수행했기 때문에 소프트웨어는 Java 컴파일러 + IDE (대부분 Eclipse), 웹 브라우저, DB 쿼리 도구, 버전 제어 클라이언트 및 때때로 사무실 sw (이 경우 OpenOffice.org)에서 사용되었습니다.

우리는 실제 문제가 발생하지 않았으며 성능은 상당히 좋았습니다.

유일한 문제는 하나의 시스템을 공유하기 때문에 어떤 상황에서는 다른 상황을 방해하지 않도록주의해야한다는 것입니다. IT 운영 부서에서 대용량 파일 복사를 수행하거나 서버에서 백업을 실행해야하는 경우 모든 사람의 성능이 저하되었습니다. 우선 순위가 낮거나 밤새 복사하여이를 확인하고 해결했을 때 모든 것이 잘 수행되었습니다.

주의 사항 : 가능한 빨리 성능을 평가하고 그에 따라 하드웨어 및 사용을 계획하십시오.

TL; DR : 여러 작업에서 해왔고 이제는 더 좋아합니다.

비용은 집중해야 할 잘못된 이유입니다. 여기 더 좋은 것들이 있습니다.

원인

• 다양한 환경 (개발, 테스트 및 프로덕션)에서의 플랫폼 일관성.
  • 이유 : 다른 환경에서 플랫폼 차이로 인한 결함 벡터, 결함을 완전히 제거합니다.
• 업그레이드와 같은 시스템 변경이 개발 vms에서 처음 발생하고, 검증되고, 롤업하여 테스트되고, 검증되고, 생산으로 롤업 할 수 있습니다. vms를 개발하고 테스트하면 훨씬 쉬워집니다.
  • 이유 : 통제. vm을 복제하여 스냅 샷, 롤백, 델타 식별, 한 서버에서 변경 수행 및 성공을 전파 할 수 있습니다.
• 때로는 개발 한 시스템을 보안 네트워크에서만 사용할 수 있습니다. 또는 소프트웨어가 실행될 서버의 액세스가 제한되거나 네트워크 특성이 다를 수 있습니다.
  • 이유 : 개발 VM은 잠긴 시스템 또는 서비스에 액세스 할 수있는 VLAN에있을 수 있습니다. 또는 개발자 서버가 테스트 및 프로덕션 서버와 동일한 제한된 액세스 권한을 가진 경우, 네트워크 특성 또는 액세스 할 수없는 액세스에 대한 요구 사항을 실수로 코딩 할 필요는 없습니다.

도전 과제

가장 어려운 문제는 원격 개발, 특히 게이트웨이 나 점프 서버를 거쳐야하는 경우입니다. 특히 개발자가 둥글 지 않은 경우 (시스템 엔지니어링 지식, 네트워킹 지식 등이 있음) 어려워집니다.

원격 개발에는 많은 변형이 있지만 일반적으로 두 가지 주요 차이점으로 요약됩니다.

• 원격 환경에서 개발 도구를 실행하고 RDP 클라이언트, 원격 X11 클라이언트 등과 같은 프로토콜을 사용하십시오.
• 개발 도구를 로컬로 실행하고 프로토콜을 사용하여 원격 서버에서 투명하게 동기화하거나 실행합니다. 종종 ssh를 전송 계층으로 사용합니다.

도구

원격 개발에 도움이되는 도구가 있으며이를 용이하게하는 IDE가 있습니다. 원격 개발이 가능한 정도를 조사해야하며, 코드가 개발되는 동일한 서버에서 실행되지 않는 경우가 많습니다. 그러나 다른 도구가 있습니다.

• 보안 셸 : 가장 성공적인 원격 개발 설정은 암호없는 로그인 (키 인증 사용), 투명 멀티 홉 (점프 서버 문제 해결) 및 기타 구성 옵션을 사용하여 응답 시간을 향상시키는 ssh를 훨씬 더 많이 사용합니다. 참고 : SSH가 아닌 OpenSSH 구현을 사용하는 데 항상 문제가있었습니다.
• GNU Screen / TMUX : 터미널 멀티플렉서. 화면은 그들 중 하나이며 여전히 강해지고 있지만, 대부분의 사람들이 TMUX에서 전환 (또는 시작)을 시작했다고 생각합니다.
• Vim / Emacs : 구식 경비원이지만 둘 다 다른 방식으로 원격 개발에 적합합니다. Vim이므로 셸만 있으면되고 Emacs는 로컬로 실행하고 원격 개발에 TRAMP를 사용할 수 있습니다.

약간 다른 방식으로-관리자 / 회계사 에게이 느린 기계 사용 비용을 강조하는 스프레드 시트를 제공 했습니까? VM 솔루션 (올바른 방법이 아니라면 쉽지 않은 경우)은 단순히 개발자와 회사를 같은 보트에 넣을 수 있다고 지적합니다.

이는 VMware 설치에 비해 관리 능력이 어느 정도인지에 따라 달라집니다. 우선 순위가 낮은 서브 풀에 배치하면 다른 서브 풀의 활동에 따라 시스템 속도가 느려집니다.

하드웨어는 싸고 프로그래머는 비싸다.

느린 개발 시스템을 제공하여 프로그래머가 왜 좌절하길 원하십니까? 하드웨어 페일 업그레이드 비용은 성능 이점과 비교합니다.

더 나은 기계를 요구하십시오. 최소한 4GB 램을 요청하십시오. 1 주일 이내에 2GB 태블릿을 추가하면 다시 적립됩니다.

듀얼 스크린 지원 부족은 항상 거래 킬러였습니다. 단일 화면에서 중요한 개발 작업을 수행한다고 상상할 수 없습니다.

이제 그들은 테스트 / 배포 / fiddling을 위해 노력하고 있으므로 스택에서 떨어지지 않아야한다고 생각합니다.

RAID10에 50 개의 SSD 디스크가있는 메인 프레임이 있고 해당 메인 프레임에서 3-4 대의 컴퓨터 만 사용하는 경우 작동 할 수 있습니다.

그렇지 않으면, 그들은 게으르다, 정말로 게으르다 (그러나 드문 경우이지만 스냅 샷은 그것을 상쇄 할 수있다).

사무실에는 괜찮은 데스크톱 컴퓨터가 있는데 화면 공유를 사용하여 VPN을 통해 랩톱에서 연결할 수 있습니다.

그것은 시간 외 지원 사고와 가끔 강제 원격 작업을 지원합니다. 두 번째 머신에서 완전히 구성된 환경을 유지하거나 WAN을 통해 데이터 센터에 낮은 대기 시간이 필요한 것을 개발하는 것보다 확실히 좋습니다.

그러나 오랫동안 그런 식으로 일하는 것은 좌절입니다. 나는 집에 머물게 된 것이 무엇이든 길을 벗어나면 하반기 동안 일을하러갔습니다.

대기 시간과 스크린 부동산은 나를위한 두 명의 살인자입니다.

나는 당신이 원격 VM 솔루션을 원한다고 생각하지 않습니다. 네트워크 연결에 병목 현상이 발생하고 빠른 연결 상태에서도 좌절을 일으킬 수 있습니다. 우리는이 기술에서 로컬 개발 환경을 사용하는쪽으로 이동하고 있습니다.

우리는 iMac을 개발하는데 정말 훌륭하지만 웹 응용 프로그램은 프로덕션 환경의 Linux 환경에서 실행됩니다. 이것의 문제는 결국 Linux에서만 발생하는 문제가 발생하여 문제를 해결하기 어려울 수 있다는 것입니다. 그것이 바로 가상 머신의 힘입니다. 그러나 저는 VM을 100 % 사용한다는 아이디어조차 좋아하지 않습니다.

나는 최근 VirtualBox 작업을 매우 쉽게 만들어주는 Vagrant (http://vagrantup.com/docs/getting-started/why.html)와 Chef에 대해 배웠습니다. Vagrant는 필요할 때 VM을 쉽게 시작하고 필요하지 않을 때는 VM을 분리 할 수있는 기능을 제공합니다. 그래서 Mac을 사용하여 모든 개발 작업을 수행 할 수있었습니다. 그런 다음 코드를 테스트 할 준비가되면 VM을 시작하여 테스트하고 필요한 기간 동안 만 유지할 수 있습니다. 또한 Vagrant는 동료와 VM을 쉽게 공유 할 수있는 기능을 제공하므로 모두 동일한 환경에서 작업 할 수 있습니다.

VM을 개발하고 작업 할 때 사용 가능한 옵션을 최소한 알고 있도록 Vagrant를 확인하는 것이 좋습니다.

나는 5 대의 기계에 관한 레거시 프로젝트를 진행해 왔으며, 각 기계는 계산 파이프 라인에서 역할을합니다 (기계 1은 기계 2에 요청을 보내고, ehich는 기계 3에 요청을 보냅니다). 그러나 가상 머신에서의 설정 배포는 우리에게 엄청난 시간을 절약 해주었습니다. 1. 개발자가 게 으르거나 디자인에 테스트를 통합 할 시간이 없었기 때문에 시스템은 논쟁의 여지가 없었습니다. 2. 너무 많은 설정이 배포되었으며 그룹으로 구성하는 데 시간이 필요했습니다.

이제 한 번에 너무 많은 프로젝트를 수행하기 때문에 사용합니다. 내가 가진 주요 문제는 다음과 같습니다. 1. VM이 유지 관리하는 데 너무 많은 시간을 소비하고 있습니다. 2. VM은 엄청난 양의 메모리를 소비하고 있습니다.

이 종류는 주문을 위해 VM을 사용하려고 할 때 VM을 사용하기 어렵게 만듭니다. 전자 메일과 텍스트를 사용하여 하나의 기본 컴퓨터를 유지하고, 차단이 해제 된 VM에서 개발하십시오. 당신의 인생을 깔끔하고 깨끗하게 유지합니다.

다른 사람들이 말했듯이 VM 데스크톱으로 해결하려는 문제에 따라 달라지며 VM 환경에서 발생하는 단점에 대해 해당 문제를 해결하는 이점을 평가합니다.

우리는 모든 육상 개발자가 기존의 물리적 머신을 보유하고 있지만, 지금은 소규모 아웃소싱 회사와 함께 일하는 해외 개발자가 가상 ​​데스크톱을 사용하는 하이브리드 환경으로 전환하고 있습니다. 원격 데스크톱으로 해결하려는 문제는 보안 및 성능과 관련이 있습니다. 가상 환경은 분명히 보안 측면에서보다 강력한 제어 기능을 제공하며 성능을 위해 전체 소스 코드가 아닌 "변경된 픽셀"만 전송하고 프록시 서버 등을 구현해야합니다.

이것이 올바른 방법인지 확실하지 않지만 우리가 향하는 곳입니다.