Linux를 사용하다 보면 permission denied되었다는 문구를 자주 마주치게 됩니다.

단발성으로 발생했을 경우는 앞에 sudo 를 붙이면 보통 해결되기 때문에, 그냥 지나치지만 docker같은 응용 프로그램을 사용할 경우, 거의 모든 명령어에 sudo를 붙여야 되서 여간 불편한게 아닙니다.

오늘은 이 불편한 행동을 생략할 수 있게 만들어주는 user 자체에 sudo 권한을 부여하는 방법에 대해 알아보도록 하겠습니다.

Root란?

Linux OS를 설치하게 되면, root라는 최상위 사용자가 생성이 됩니다. 이 root는 모든 권한을 가지고 있는 관리자로 root 계정으로 들어갈 경우, 모든 디렉토리나 파일에 접근할 수 있고, 수정 및 생성, 삭제까지 진행할 수 있습니다.

따라서 이 root라는 관리자는 매우 중요한 역할을 하며, 실수로 필수적인 파일들을 삭제하지 않기 위해 유저에게 sudo 권한을 부여해서 사용하는 것입니다.

하지만 이런 점은 개인이 사용하는 PC에서는 보통 중요하지 않습니다. 그저, 명령어를 빨리 입력하기를 원할 뿐이죠.

계정에 권한 주는 방법

현재 사용하는 계정에 권한을 주는 방법은 다음과 같습니다. 우선 지금 부여하려는 계정의 정보를 확인합니다. 정보는 Terminal에 whoami라고 적으면 현재 내가 들어와있는 계정이 어떤 것인지 표현됩니다.

이후, visudo라는 명령어를 사용하면 /etc/sudoer 파일에 접근할 수 있습니다.

맨 하단에, 사용자의 이름과 권한을 부여한다는 내용을 추가해주면 됩니다.

저의 경우 추가로 패스워드 생략까지 부여했습니다.

Docker에 권한 주는 방법

추가로, docker에 sudo 권한을 주는 방법은 다음과 같습니다.

$sudo usermod -aG docker {user id}
// usermod : user의 속성을 변경하는 명령어입니다.
// -G : 새로운 그룹을 말합니다.(group)
// -a : 다른 그룹에서 삭제 없이 Group에 해당 User를 추가하는 옵션입니다.(append)

이후, sudo 없이 명령어가 정상적으로 작동되는 것을 볼 수 있습니다.

Layer란 무엇일까요?

Yocto 내에서 관련이 있는 Recipe들을 모아놓은 곳을 Layer라고 부르며, naming을 Meta-으로 규약하고 있습니다.

이전에 받아 놓은 poky directory를 한번 살펴보도록 하겠습니다.

Poky directory 분석

poky directory를 보면 meta, meta-poky, meta-selftest, meta-skeleton, meta-yocto-bsp라는 layer들이 존재하고 있는 것을 볼 수 있습니다.

이것들은 yocto project를 구성하는 핵심 layer이며, 이것들 뿐만 아니라 개발자는 custom layer를 생성하여 기능적인 요소들을 추가할 수 있습니다.

yocto에서 굳이 layer를 만들어 사용하는 이유는 무엇일까요? 그것은 바로 내부 컴포넌트들을 좀 더 체계적으로 관리하기 위해서입니다. 구성 layer 중 하나인, meta-poky의 구조를 예로 살펴보도록 하겠습니다.

한편, 디렉토리 구조를 살펴볼 때, 저는 tree라는 명령어를 사용합니다.

tree는 폴더의 하위 구조를 계층적으로 표시해주어서 전체 디렉토리 구조를 파악할 때 유용하며, -L 옵션을 사용하여 얼마나 자세히 구조를 표현할 지 결정합니다.

$apt-get install tree

이런식으로 layter는 conf, recipe, classes, 그리고 이외 항목들을 종류에 맞게 체계적으로 분리하여 좀 더 깔끔하게 yocto를 사용할 수 있게 만들어 줍니다.

Create Layer

오늘은 이 layer를 직접 만들어보는 시간을 가져보도록 하겠습니다. Layer를 만들기 위해 제일 먼저 수행해야 하는 것은 빌드에 대한 기본 환경을 구성해주는 것입니다. 하는 방법은 다음과 같습니다.

$source oe-init-build-env [build_directory_name]

이 과정을 통해 build라는 directory가 자동으로 생성되었고 build를 현재 directory로 만들었습니다. 보통 이 작업을 할 때 아무 값도 지정하지 않으면, 다음과 같이 ARM QEMU emulator가 자동으로 생성됩니다.

이것에 대한 설정은 conf/local.conf에서 확인할 수 있는데 우선 맨 앞에 있는 bblayer.conf부터 순차적으로 살펴보도록 하겠습니다.

bblayer.conf

bblayer.conf는 poky가 build를 진행할 때 어떤 레이어를 사용할 것인지 정의해 주는 공간입니다.

방금 poky 디렉토리에서 봤던 meta, meta-poky, meta-yocto-bsp가 있는 것을 볼 수 있습니다.

개발할 때 필요한 bsp-layer나 custom으로 만든 layer들의 경로들을 여기에 추가해서 사용하시면 됩니다

local.conf

local.conf는 target machine과 crosscompiler와 같은 빌드하는데 필요한 설정들을 해주는 공간입니다.

방금 얘기했던 데로 현재 qemux86-64가 default로 설정되어있으며, target을 바꾸고 싶다면 해당 machine에 있는 주석을 해제해서 사용하시면 됩니다. Layer를 만드는데 필요한 구성 요소들을 어느 정도 알아본 것 같으니 이제 Layer를 만들어보도록 하겠습니다.

Layer를 만드는 명령어는 다음과 같습니다.

$bitbake-layers create-layer meta-<LAYER NAME>

meta-test layer를 create 한 후 디렉토리를 확인해보면 실제로 meta-test layer가 디렉토리에 생성되어 있는 것을 확인할 수 있습니다.

그 다음 할 작업은 생성한 layer를 mybuild/conf/bblayer.conf에 추가하는 것입니다.

layer가 잘 추가되었는지 확인해보려면 example recipe를 사용하면 됩니다. example recipe는 layer를 생성하면서 자동으로 생기며, bitbake test를 할 때 사용합니다.

문제 없이 bitbake가 완료 되었다면 성공적으로 layer가 구성된 것입니다.

Ubuntu를 처음에 깔았을 때 분명 한글로 환경설정을 하고 Install을 진행했는데, 막상 다 깔고 나니 영어로 전부 설정되어 있고 한글은 입력되지도 않아서 고생을 좀 했었습니다.

시간이 좀 지나 VMware를 초기화하고 또 같은 문제로 인해 시간을 좀 소비하게 되서, 다른 분들은 좀 더 편하게 작업을 진행하시기를 바라면서 방법을 정리하게 되었습니다.

ibus install

$ sudo apt install ibus ibus-hangul

Hangul font install

$ sudo apt install fonts-noto-cjk

im-config file modify

$ sudo vi /etc/default/im-config

*IM_CONFIG_DEFAULT_MODE=auto --> IM_CONFIG_DEFAULT_MODE=ibus 로 수정!! *

Input Method Setting

im-config를 입력하면 Input Method가 나옵니다.

여기서 ok를 누르다가 Select user configuration이 나오면 ibus를 선택한 후, Ok를 누르고 다 진행했으면 reboot를 진행합니다.

Ibus Preferences 실행

Ibus Preferences는 Terminal에서 ibus-setup을 치면 실행됩니다.

Input Method에서 Add --> Korean을 검색한 후, Hangul 아이콘을 클릭해줍니다.

Setting 한국어로 변경 / 단축키 지정

위의 과정을 다 진행하고 나면 우측 상단 바에 ibus 아이콘이 표시되는 것을 볼 수 있을 것입니다.

단축키를 변경하고 싶다면, Setting - Keyboards- layout에서 한국어-Preferences를 들어가면 원하는 키로 한영 전환키를 등록할 수 있습니다.

이전에 만들었던 docker의 환경을 setting하는 시간을 가져보도록 하겠습니다.

Locale Setting

우선 만들어 놓은 container를 update 시켜줍니다.

$ apt-get update

환경을 setting 하기 전에 제일 먼저 해줘야 할것은 locale 설정입니다. locale에 대한 자세한 설명은 아래 포스팅을 참고하시기 바랍니다.

Locale이란?

현재 locale을 보면 아무것도 setting을 안해놓은 상태기 때문에 보이는 것과 같이 텅 비어있습니다.

이 비어있는 locale을 원하는 환경에 맞게 setting 해줍니다.

$ apt-get install sudo locales vim
$ locale-gen en_US.UTF-8

Package 설치 (Ubuntu / Debian)

Docker container는 local pc와는 별개로 움직이기 때문에 필요한 package들을 따로 받아줘야 합니다.

저의 경우, 해당 docker를 yocto를 학습하는데 사용할 예정이기 때문에 yocto를 사용하는데 필요한 패키지를 다운받도록 하겠습니다.

해당 command는 다음과 같습니다.

$ apt-get install -y \
    g++ gawk wget git git-core diffstat unzip texinfo \
    gcc-multilib build-essential chrpath socat cpio libncurses5-dev \
    python3 python3-pip python3-pexpect xz-utils debianutils \
    iputils-ping python3-git python3-jinja2 libegl1-mesa \
    libsdl1.2-dev pylint3 make xsltproc docbook-utils locales \
    fop dblatex xmlto xutils-dev autoconf automake libtool \
    libglib2.0-dev libarchive-dev python-git live-build \
    debootstrap qemu-user-static python-pip \
    xterm python3-subunit mesa-common-dev zstd liblz4-tool \
    lib32z1 lib32stdc++6 bc sudo tmux python-crypto

20분정도 기다린 결과, 인스톨이 전부 완료되었습니다.

Docker commit

자, 이제 지금까지 세팅한 내용들을 다시 이미지화하도록 하겠습니다.

명령어는 다음과 같습니다.

//docker commit <container name> <new docker image name>:<version>
$ docker commit ubuntu jaehyeon

Docker run / exec

이번에 run하는 docker container에는 restart always와 -v 옵션을 추가합니다.

restart 옵션을 줄 경우 docker desktop을 실행시킬 때 마다 항상 container를 같이 띄울 수 있습니다.

v 옵션을 사용하는 이유는 Local과 volume을 공유하기 위해서입니다.

docker container가 volume을 사용하려면 volume을 컨테이너에 마운트 해주는 과정을 진행합니다.

-v 옵션을 통해 이 과정을 진행하는데 :을 구분자로 해서 앞에는 마운트할 volume, 뒤에는 container 내의 경로를 적어주면 됩니다.

// docker run --restart always --name <container name> - v <local location>:<Docker location> -dt <image name>
$ docker run --restart always --name jaehyeon -v /home/jaehyeon/work:/home/jaehyeon/work -dt jaehyeon

이제 run한 docker container를 exec 합니다.

$ docker exec -it jaehyeon /bin/bash

보이는 것과 같이 volume이 docker에 잘 마운트 되어 있는 것을 볼 수 있습니다.

Locale이란, 각 나라별로 가지고 있는 언어, 날짜 등에 관해 같은 프로그램이라도 어떤 방식으로 출력할지 결정하게 해주는 문자열입니다.

한국에서 현재 날짜를 2023년 7월 2일이라고 표현한다면 다른 나라에서는 02/07/2023이라고 표현할 수 있겠죠.

이처럼 개발자가 해당 국가의 출력 형태를 결정해주도록 알려주는 것이 Locale입니다.

한국의 Locale은 보통 ko_KR.UTF-8을 사용합니다.

Locale 설정 방법

로컬 terminal에서 locale이 어떻게 설정되었는지 확인해 보도록 하겠습니다.

설정을 확인하는 커맨드는 다음과 같습니다.

$ locale

보이는 것과 같이 ko_KR.UTF-8로 설정되어있습니다.

한글로 설정되어있는 locale을 영어로 바꿔보도록 하겠습니다.

우선 영어용 패키지를 설치하겠습니다.

$ sudo apt-get install language-pack-en

영어 패키지의 경우, 보이시는 것과 같이 리눅스를 깔 때 이미 설치되어있는 경우가 많습니다.

패키지가 설치되어있는 것을 확인했으니, 이제 Locale을 설치해줍니다.

$ sudo locale-gen en_US.UTF-8

generation이 무사히 완료되었습니다.

이 방법 말고도, 직접 locale 파일을 수정해서 설정을 변경하는 방법도 있습니다.

$ vi /etc/default/locale

해당 값을 변경한 후, reboot을 하면 설정이 제대로 변경되어 있는 것을 확인할 수 있을 것입니다.

Docker를 install 하는 과정을 다뤄보도록 하겠습니다.

Apt package install

설치되있는 패키지를 모두 새버전으로 업그레이드 시킨 후 , apt 패키지 설치를 진행합니다.

$ sudo apt-get update
$ sudo apt-get install \
    ca-certificates \
    curl \
    gnupg \
    lsb-release

Docker의 공식 GPG Key 추가

변조된 docker image를 받는 것을 방지하기 위한 공식 GPG Key를 추가합니다.

$ sudo mkdir -p /etc/apt/keyrings
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

Repository setting

//arm64

$ echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

//x86,amd64
$ echo \
  "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Docker engine install

진행한 사항에 대한 update를 진행한 후, 다시 install을 진행하면 도커 설치가 완료됩니다.

$ sudo apt-get update
$ sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin

간단한 command를 통해 docker가 잘 install 되었는지 확인할 수 있습니다.

$sudo docker run hello-world

docker를 만드는 과정을 진행하기에 앞서서 docker는 대체 왜 사용하는 걸까요?

docker를 사용하는 주된 이유는 개발환경을 이미지화 시켜서 개발 및 배포 환경을 컨테이너화 할 수 있기 때문입니다.

개발을 하다 보면 분명히 내 자리에서 빌드가 잘 되는 것을 확인하고 팀원들에게 배포를 진행했는데, 꼭 한-두명 씩 에러가 나는 경우가 있습니다.

물론 다른 문제로 인해서 에러가 난 경우도 있겠지만, 원인을 분석해보면 플랫폼이나 프레임워크의 버전이 달라서 발생하는 경우가 많습니다.

이것에 대한 해결책으로 저는 docker를 사용하고 있습니다.

팀원들과 같은 버전인 플랫폼, 프레임워크를 이미지에 올려놓고 컨테이너로 만들고 이 컨테이너에서 돌리면 로컬이랑 별개로 독립적으로 작업을 진행할 수 있기 때문에 관련 이슈들을 쉽게 해결할 수 있습니다.

또한, 빌드 중 치명적인 에러가 발생했을 경우에도 그저 관련 컨테이너만 제거하면 되기 때문에 안전성도 보장된다는 장점이 있습니다.

Docker image pull

이제 docker hub 에 있는 ubuntu docker image를 setting해보는 시간을 가져보도록 하겠습니다.

ubuntu image의 경우 docker hub 사이트에 들어가서 ubuntu를 검색해보면 ubuntu 의 버전과 그에 맞는 image들을 쉽게 찾아 볼 수 있습니다.

Docker hub Link

저는 ubuntu 16.04 version image를 받아서 진행하였습니다.

$ docker pull ubuntu:16.04

docker image가 잘 pull 되었는지 확인합니다.

$ docker images

맨 하단에 ubuntu 16.04 image가 생성되어있는 것을 확인할 수 있습니다.

Docker image로 container run / exec 해보기

이제 docker 컨테이너를 run해 보도록 하겠습니다.

$ docker run --name <conatiner name> -dit <docker image>

여기서 사용하는 옵션은 다음과 같습니다.

--name : container name

-d : background에서 사용합니다.

-it : 컨테이너를 종료하지 않은 채로 터미널의 입력을 계속 컨테이너로 전달하기 위해 사용해야 하는 옵션입니다.

container가 잘 생성되었는지 확인합니다.

$ docker ps

run 하고 있는 container에 접속하는 command는 다음과 같습니다.

$ docker exec -it [container id] /bin/bash

hostname이 해당 container id로 바뀐 것을 볼 수 있습니다.

docker stop / kill

exit 명령을 통해 접속 종료가 가능하며, docker container를 종료하는 명령어는 다음과 같습니다.

$ docker stop [container id] // 해당 컨테이너 종료
$ docker kill [container id] // 해당 컨테이너 강제 종료

보이는 것 과 같이 실행 중이었던 container가 내려간 것을 볼 수 있습니다.

docker kill command를 사용할 경우, 말 그대로 container가 강제 종료가 되는 것이기 때문에, 이후에 사용할 때 conflict error가 발생할 수 있습니다.

따라서, 심각한 문제로 강제 종료하는 경우가 아닐 경우 왠만하면 docker stop으로 container를 종료하는 것이 좋습니다.

Docker restart/remove image

docker restart는 종료한 container를 다시 시작하게 해주는 명령어이며, docker container 및 image를 지우는 명령어는 다음과 같습니다.

$ docker restart [container id] // 해당 컨테이너 다시 시작
$ docker rm //conatiner 삭제
$ docker rmi //image 삭제

격리된 가상화된 환경이란, OS를 가상화 시키는 것이 아닌 프로세스를 분리하여 독립적으로 실행할 수 있게 해주는 환경을 말하며, 여기선 Container라고 부릅니다.

Container의 대표적인 예로는 LXC(Linux Container)가 있습니다. LXC는 물리적 자원을 관리하는 Kernel space와 User process(Application)을 실행하는 User space로 나뉩니다. kernel 내부에서는 CPU, Memory를 할당해주는 Cgroups와 namespace를 결합하여 가상화 머신을 시작할 필요없이 고립된 환경을 제공하여 독립적으로 이를 활용할 수 있게 해줍니다.

Docker 또한, 이러한 Linux Container를 기반으로 구축되었으며 Cgroups 및 namespace와 같은 커널의 기능을 사용하여 프로세스를 분리하여 독립적으로 실행할 수 있게 해줍니다.

하지만, Docker는 전통적인 Linux 컨테이너와는 다릅니다. LXC는 경량의 가상화 방법으로 유용했지만 개발자에게 뛰어난 사용자 환경을 제공하지는 못했습니다. init system을 사용하여 전체 애플리케이션을 하나로 실행할 수 있는 LXC와는 다르게 Docker는 애플리케이션을 개별 프로세스로 세분화시킬 수 있습니다. 이렇게 해줌으로써 Docker는 컨테이너 생성 및 구축, 이미지 전송, version을 관리하는데 좀 더 편리하게 사용할 수 있다는 장점을 가지고 있습니다.