도커는 큰 고민 없이 쓰면 되는 줄 알았다.
어떤 컴퓨터에서 띄우든 동일한 개발환경을 제공하는 것이 큰 강점이기 때문이다.
그러나 팀원들끼리 협업하면서 그런 생각이 문제라는 것을 깨달았다.
어떤 도커 이미지가 window에서는 정상 동작하지만 mac에서 돌아가지 않았던 것이다.
처음 문제를 발견했을 때는 docker-compose.yaml에 platform을 다음과 같이 명시하는 것으로 해결이 되었다.
이때 직접적으로 느꼈다. 도커 이미지들이 호스트 시스템에 영향을 이런식으로 받는다는 것을..
* 참고로, 내 window에서는 명시 안해도 오류 안터졌는데, 나와 같은 amd64인 M1에서는 저 문제가 터졌다. amd64라고 명시하고 다시빌드하니까 해결되었다.
* M2에서는 arm64/v8이라고 명시해주어야 문제가 발생하지 않았다.
docker-compose.yaml의 해당 서비스에서 platform 속성을 명시하여 해결!
[intel & M1]
platform: linux/amd64
[M2]
platform: linux/arm64/v8
(꽤 시간이 오래 지나.. 바로 오늘!)
다른 팀원에게 똑같은 문제가 생겼다.
그래서 좀 더 차분하게
근본적인 이유를 찾아나섰다.
docker hub에서 지금 사용중인 이미지인 openjdk:17-alpine에 대한 정보를 찾아보았다.
이래서 안 됐던 거였어! 애초에 팀원의 arm64/v8에서는 호환되지 않는 이미지였다.
저렇게 도커 이미지에 OS/ARCH가 명시되어 있는 것은 처음 알았다. 기쁜 발견이었다.
다른 openjdk 이미지도 구경해보니까, 둘다 지원하는 것도 있고 하나만 지원하는 것도 있더라.
=> 그럼 둘다 명시되어 있는걸 사용하면 되겠다!
기존: openjdk:17-alpine을 사용중이었다.
변경: openjdk:17-buster로 바꾸고, 당연히 apine환경에서 사용하던 apk를 apt-get로 바꾸었다.
* 일반 openjdk:17은 데비안(리눅스)환경이 아닌가보다. apt-get이 기본적으로 없었다.
.
.
빌드 성공! 컨테이너 띄우기 성공!
아마도 이제부터는 우리팀에게 이런 문제는 일어나지 않을 것이다.
내 시스템의 amd64, 팀원 시스템의 arm64/v8 platform이 모두 호환이 되는 openjdk 이미지로 바꾸었기 때문이다.
(저번에는 왜 됐지? 그리고 왜 갑자기 안됐지? 그건 못 찾았다. 몰라서 좀 슬프지만 넘어간다.)
'컴퓨터구조 & OS' 카테고리의 다른 글
[WSL와 VM의 차이점] 하이퍼바이저를 이해하며.. (2) | 2023.09.07 |
---|---|
도커는 호스트 시스템에 영향을 받는다 2편 - tensorflow 관련 ImportError (1) | 2023.07.05 |
[컴퓨터구조] 파이프라이닝 | 개념, 성능, 문제점 (0) | 2021.11.19 |
[컴퓨터구조] 16비트 컴퓨터에서 프로그래밍하기 - Assembler가 어셈블리 프로그램을 기계어로 번역하는 과정 (0) | 2021.10.18 |
[컴퓨터구조] 16비트 컴퓨터에서 프로그래밍 하기 | assembly로 쓰여진 프로그램의 구조 (0) | 2021.10.18 |