![새 배포판에 컴파일된 이전 배포판의 애플리케이션 배포](https://linux55.com/image/192772/%EC%83%88%20%EB%B0%B0%ED%8F%AC%ED%8C%90%EC%97%90%20%EC%BB%B4%ED%8C%8C%EC%9D%BC%EB%90%9C%20%EC%9D%B4%EC%A0%84%20%EB%B0%B0%ED%8F%AC%ED%8C%90%EC%9D%98%20%EC%95%A0%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98%20%EB%B0%B0%ED%8F%AC.png)
ubuntu:latest 의 docker 컨테이너에 기반으로 빌드된 바이너리가 있는데, ubuntu 20
예를 들어 ubuntu:latest 에서 이 바이너리를 실행하려면 어떻게 해야 합니까 ubuntu 16
?
나는 우분투 16의 버전이 바이너리가 연결된 libc.so
우분투 20의 버전과 호환되지 않는다는 사실에 직면할 수 있다는 것을 알고 있으며 .libc.so
GLIBC symbols is not found
이 상황에서 가장 좋은 방법은 무엇입니까? 시스템 라이브러리와의 정적 링크 및 각 대상 플랫폼에서의 구축은 고려되지 않습니다.
빌드 플랫폼에서 대상 플랫폼까지 모든 시스템 공유 라이브러리( 등)를 사용할 수 있게 libc
만드는 방법은 무엇입니까 ? ubuntu 16에서 실행되는 내 응용 프로그램은 연결된 ubuntu 20을 사용합니다 . (예를 들어 원하는 경유 경로를 지정합니다 )libpthread
ld.so
libc
libc
LD_LIBRARY_PATH
이 접근 방식을 사용하면 어떤 문제에 직면하게 됩니까?
답변1
이전 배포판에서 "새로운" 바이너리를 실행하는 데 필요한 모든 것을 제공하려고 하면 결국 복잡해지고 다소 불안정해집니다. 관심이 있다면 Steam 런타임이나 Flatpak 런타임을 확인하세요. 전체 생태계를 위해서는 그만한 가치가 있지만 단일 바이너리에는 너무 많은 노력이 필요하다고 생각합니다.
바이너리를 빌드할 수 있는 컨테이너 설명자가 이미 있으므로 모든 대상 배포에 대해 조정하는 것이 좋습니다. 이렇게 하면 모든 곳에서 올바른 종속성을 사용하여 바이너리를 빌드할 수 있으며 종속성이 필요한지 여부를 사용자가 알기 전에 알 수 있습니다. 조정되었습니다.
반드시 배타적이지는 않지만 다른 옵션도 있습니다.
컨테이너 이미지에 바이너리를 제공하도록 선택할 수 있습니다. 컨테이너가 잘 구축되면 오버헤드가 최소한으로 줄어들 수 있습니다. 실제로 바이너리에 필요한 런타임을 제공하는 데 필요한 오버헤드는 현재 고려 중인 옵션과 동일하며 훨씬 덜 취약합니다.
고려해야 할 또 다른 옵션은 바이너리를 정적으로 구축하거나 최소 공통 분모(예를 들어RHEL7). 새 릴리스에 대한 오래된 종속성으로 인해 가용성 문제가 발생할 수 있지만 일반적으로 이러한 문제는 첫 번째 접근 방식보다 더 나은 방법으로 해결될 수 있습니다.