실제 VM을 띄우지 않으면 VM 규모 조정 수학을 테스트할 수 없다
출처: Dev.to
WhonixAutoSetup은 Security+를 준비하면서 계속 손대고 있는 PowerShell 프로젝트입니다. Windows에서 Whonix를 구동합니다: 하나의 VM은 Tor (게이트웨이)로 실행되고, 두 번째 VM는 첫 번째 VM(워크스테이션)를 통해 모든 트래픽을 라우팅합니다. 따라서 워크스테이션은 Tor가 아닌 인터넷 경로에 전혀 연결되지 않습니다. 네 개의 스크립트를 순서대로 실행합니다.
이 중 하나인 configure- vms.ps1 스크립트는 각 VM에 할당할 메모리와 코어 수를 결정합니다. 게이트웨이는 1코어, 1GB로 고정되어 있으며 Tor는 더 이상 필요하지 않습니다. 워크스테이션은 호스트와 비례하여 24코어, 사용 가능한 RAM의 2540% 범위 내에서 동작하며, 바닥(floor)이 있어 부팅 가능한 상태로 유지되고, 상한(ceiling)이 있어 전체 기계를 삼켜버리지 않도록 합니다.
그것은 스크립트에서 실제 로직이 있는 유일한 부분입니다. 계층(tier), 바닥(floor), 상한(ceiling), 반올림(step)이 포함됩니다. 그리고 작년 말까지는 테스트가 전혀 없었습니다.
왜 테스트가 없었을까
함수는 하드웨어를 읽고 동시에 수학을 수행했습니다:
function Get-ResourceAllocation {
$totalRam = (Get- CimInstance Win32_ComputerSystem).TotalPhysicalMemory
$cores = (Get- CimInstance Win32_Processor).NumberOfLogicalProcessors
# ...then ~30 lines of tiering, flooring, and rounding on those two values
}Enter fullscreen mode
Exit fullscreen mode
이를 테스트하려면 실제 Windows 호스트가 CIM에서 실제 값을 반환하도록 해야 합니다. 예를 들어 6GB 계층이 의도한 대로 반올림되는지 확인하려면 6GB 규모의 기계를 찾아 전체 스크립트를 실행해야 합니다. 저는 다양한 RAM 크기의 머신을 보유하고 있지 않고, 오직 제 노트북만 가지고 있습니다. 따라서 수학은 정확히 한 번, 정확히 하나의 메모리 크기에서만 검증되었고, 다른 사람들은 제 crossed fingers(뺏은 손가락)을 받았습니다.
이것은 역으로 되어 있습니다. CIM 호출은 제가 제어할 수 없으며 테스트해서는 안 되는 부분이며, Microsoft의 것입니다. 연산은 제가 작성한 부분이고 실제로는 깨지는 부분입니다. 제가 cared(관심)했던 부분은 테스트가 불가능하도록 만든唯一的 요소와 결합되어 있었습니다.
수정은 평범하지만, 그것이 전부인 점입니다. 수학을 기계가 아니라 숫자를 받는 함수로 분리합니다:
function Get-VmResourceAllocation {
param(
[long]$TotalRamBytes,
[int]$CoreCount
)
# same tiering, flooring, rounding, now operating on parameters
# returns the same allocation hashtable as before
} configure- vms.ps1는 여전히 CIM 읽기와 로깅을 수행하지만, 이 보조 함수에 두 숫자를 전달합니다. 입력은 동일하고 previously 반환된 해시테이블과 동일하므로 실제 실행 결과도 변하지 않습니다. 따라서 실제 사용자에게는 아무 변화가 없습니다.
변경된 점은 이제 VM이나 VirtualBox 없이, 깨끗한 CIラン너에서 이렇게 할 수 있다는 것입니다:
It 'leaves a core for the host and never drops below one' {
(Get-VmResourceAllocation -TotalRamBytes 8GB -CoreCount 1).Cores | Should -Be 1
(Get- VmResourceAllocation -TotalRamBytes 8GB -CoreCount 4).Cores | Should -Be 3
} 열두 개 케이스는 이제 세 RAM 계층, 2GB 워크스테이션 바닥, 8GB 상한, 128MB 반올림 단계, 그리고 코어 캡을 모두 커버합니다. 이 테스트는 Pester를 사용해 모든 푸시 시 실행되며, VirtualBox와 파일시스템을 모킹하여 하이퍼바이저 없이 어디서든 실행될 수 있게 합니다.
제가 가장 확신이 없었던 경우는 단일 코어 호스트였으며, 저렴한 클라우드 박스와 같은 상황을 의미합니다. 실제로 오래된 함수가 한 코어를 받었을 때 어떤 행동을 했는지 jamais 확인한 적 없었습니다. 테스트를 작성함으로써야 비로소 확인할 수 있었습니다: “호스트용으로 하나 남겨두는” 분기문이 0이 아니라 1을 반환한다는 것을. 올바른 동작을 합니다. 하지만 “가능성 있게 올바르게 동작한다”는 것은 VM 부팅 여부를 결정하는 코드에 배포하기에 적합하지 않으며, 그것이 바로 기존 상태였습니다.
아직도 개선할 점이 있습니다
CIM 읽기는 아직 테스트되지 않았습니다. 저는它们을 모킹합니다. 즉, Windows가 TotalPhysicalMemory를 다른 형태나 단위로 반환하더라도 테스트는 초록색으로 남아 실제 실행은 깨질 수 있습니다. 제가 그 경계를 그었다고 믿는 것이죠. 이는 이런 분할의 일반적인 비용이지만, 초록 체크마크가 실제 커버리지보다 더 많다고 암시하는 것을 피하기 위해 명백히 말해야 합니다.
RAM 백분율도 여전히 if 분기 안에 있는 마법 숫자 상태입니다. 여기 25, 거기 40 등입니다. 이미 테스트되었으므로 변경은 안전하지만, 파일 상단에 작은 테이블로 두는 것이 로직을 깔끔하게 정리하는 방법이며, 아직 수행하지 못했습니다.
계속 relearning하는 점
한 코드 조각이 실제 인프라를 사용해 전체 프로그램을 실행해야만 테스트할 수 있다면,那是 보통 테스트 문제가 아니라 seam(결합점) 문제입니다. 로직과 I/O가 결합되어 있으며, 해결책은 외부에서 더 큰 테스트 환경을 구축하는 것이 아니라它们을 분리하는 것입니다.
이걸 알고 있었기에, 저는 먼저 결합된 버전을 배포했습니다. 그것은 줄이 적고 제 머신에서 잘 실행되었습니다. 이제 더 많은 기계에서도 잘 실행되며, 제가 직접 소유하지 않아도 증명할 수 있습니다.
코드를 원하시면 GitHub: github.com/TiltedLunar123/WhonixAutoSetup