Android, Cocos2d, Java Web, Linux, reading...

소스트리(Source Tree)에서 브랜치(Branch) 따기
27 Jan 2019

이번 포스팅에서는 소스트리(Source Tree)에서 브랜치(Branch)를 따는 방법에 대해서 알아보고자 한다. 그 전에 브랜치가 무엇인지에 대해서 알아보자.

阅读全文 »

소스트리(Source Tree)를 저장소(repository)와 연결하기
11 Jan 2019

이번 포스팅에서는 소스트리(Source Tree)에 대해서 알아보고자 한다. 소스트리가 무엇인지부터 알아보자.


  • 소스트리(Source Tree)란:

    Atlassian에서 개발한 git을 GUI로 사용자가 더 쉽게 사용할 수 있도록 해주는 프로그램이다. 이 소스트리는 Windows와 Mac OS를 지원하고 있으며 라이센스는 무료이다.

설치는 https://www.sourcetreeapp.com/에서 할 수 있다.

필자도 Windows를 사용하기 때문에 Windows용을 다운받았다. 설치방법은 검색하면 많이 나오기 때문에 생략하고 설치됐다고 가정하고 진행하겠다.

다 설치가 됐으면 이렇게 화면이 나와야 한다.

저번 포스팅에서 로컬 저장소(repository)와 git 저장소를 서로 연결시켜 관리했는데 이 소스트리로 로컬 저장소와 연결시켜 git 저장소를 관리해준다고 생각하면 된다. 그럼 git 저장소를 소스트리로 관리해보자. 현재 필자의 git 저장소는 이러하다.

필자는 여기서 backjoon_algorithm 저장소를 소스트리로 관리할 예정이다. 그럼 먼저 로컬 저장소와 git 저장소를 서로 연결시켜주자. git 저장소를 연결시킬 로컬 저장소에서 Git Bash를 연 다음

이대로 해주면 로컬 저장소에 git 저장소의 파일들이 나타나게 된다.

각 명령어에 대한 설명은 저번 포스팅에 다 있으므로 생략하겠다.

(참고 : git 저장소 URL은 ‘Clone or download’을 누르면 확인할 수 있다.)

다시 돌아와서, 이제는 소스트리를 로컬 저장소와 연결시켜보자.

여기서 Add 부분을 클릭한다.

그 다음 ‘탐색’ 부분을 눌러 해당 로컬 저장소를 지정해주고 ‘추가’ 버튼을 클릭하면

이렇게 과거부터 현재까지 했던 작업들이 쭉 나오게 된다. 이러면 성공한 것이다. 다음 포스팅에서는 작업을 한 후 해당 내용을 commit, push 해보자.



참고 블로그 :

  • http://donbada.tistory.com/73

阅读全文 »

Docker 컨테이너 백업
13 Dec 2018

이번 포스팅에서는 Docker 컨테이너 자체를 백업하는 것에 대해서 다루려고 한다.

  • Docker 컨테이너 백업

: Docker 컨테이너(그냥 컨테이너라고 하겠습니다.)에서 여러 작업들을 하다가 컨테이너가 문제가 생겨 내렸다가 다시 띄우면 컨테이너 자체가 휘발성이므로 작업했던 것들이 모두 없어진다. 물론 저번 포스팅들에서 배웠던 것처럼 이런 특성 때문에 Docker-Volume이라던지 호스트 볼륨이라던지 등등 볼륨들을 놓아 데이터들을 유지시켰지만 이런 데이터들 말고 툴 같은 것들이 설치된 경우는 볼륨으로 관리하기가 너무 까다롭다. 거기다 툴이 하나면 모를까 여러 개가 설치된 경우는 더더욱 관리하기가 어렵다. 이런 경우에는 컨테이너 자체를 백업하는 게 좋다. 컨테이너를 백업한 후(정확히는 컨테이너에 해당하는 이미지를 백업) 백업한 것을 다시 실행시켜주면 해당 작업들이 그대로 유지되어 있기 때문이다. 이제 백업하는 방법에 대해 알아보자. 먼저 백업할 컨테이너를 띄워보겠다.

$ docker run -it –rm ubuntu:16.04 /bin/bash

그 다음 작업한 상태를 가정하기 위해 pooh.txt 파일을 추가해준다.

$ echo ‘1’ > pooh.txt

이제 이 컨테이너 자체를 백업해보자.


(1) 컨테이너 상태 저장하기

백업하기 전에 컨테이너 상태를 먼저 저장해야 한다. –rm 옵션이 있어서 해당 컨테이너를 나가면 바로 삭제되기 때문에 터미널을 하나 더 켜서 새로운 터미널에서 해당 명령을 입력해보자.

현재 우리가 띄우고 있는 ubuntu:16.04 컨테이너이다. 이를 저장할 것이다. [컨테이너 이름 or ID] 부분에서 필자는 컨테이너 ID를 택했다.

$ docker commit [옵션][컨테이너 이름 or ID] [저장할 이미지 이름]:[태그]

$ docker commit -p a1a5db3887ee pooh_backup:test
(-p 옵션을 주지 않아도 똑같이 동작하긴 하는데, -p 옵션은 commit하기 위해 해당 컨테이너를 일시중지시키는 옵션이다.)

docker images를 통해 확인해보면 pooh_backup:test라는 이름의 도커 이미지가 잘 생성되었다. 실제 저 pooh_backup:test라는 이미지를 컨테이너로 실행시켜보면

아까 만들었던 pooh.txt가 있는 것을 확인할 수 있다.

(2) 백업하기

도커 이미지가 있는 곳으로 commit한 이미지가 저장된 것으로 보아 이 자체가 백업이라고 생각할 수 있는데 docker가 삭제되면 도커 이미지들도 모두 삭제되기 때문에 해당 이미지를 압축파일로 저장해서 호스트에 저장하는 방식으로 백업해야 한다.

$ docker save -o [저장 경로][저장할 파일이름].tar [이미지 이름]

$ docker save -o /home/pooh/test14/pooh_backup.tar pooh_backup:test

단, 저장 경로는 반드시 만들어져 있는 디렉토리여야 한다. 그렇지 않으면 밑의 화면처럼 없는 경로라고 에러가 뜬다.



(3) 복원하기

도커 이미지가 없는 상태에서 잘 동작하는지 확인하기 위해 백업하면서 만들어졌던 pooh_backup:test 이미지를 지워보자.

$ docker rmi pooh_backup:test

docker images로 보게되면 pooh_backup:test 이미지가 없다.

이제 해당 이미지를 복원해서 컨테이너로 실행시켜보자. 복원하는 방법은 이렇다.

$ docker load < [저장 경로][저장할 파일이름].tar

$ docker load < /home/pooh/test14/pooh_backup.tar

pooh_backup:test라는 이미지가 다시 생성되었다. 이제 컨테이너로 실행해서 아까 추가했던 pooh.txt 파일이 그대로 있는지 확인해보자.

$ docker run -it –rm pooh_backup:test /bin/bash

pooh.txt 파일이 있음을 확인할 수 있다.



참고 사이트 :

  • https://m.blog.naver.com/chandong83/221006388637

阅读全文 »

사용하지 않는 Docker-Volume 삭제하기
05 Dec 2018

Docker-Volume에서 이런저런 테스트를 하다보니 불필요한 Docker-Volume들이 많이 생겼다.
(Docker-Volume 경로 : /var/lib/docker/volumes/)

그림에서처럼 진짜 어마어마하게 많았다(너무 많아서 중간에서 잘랐습니다). 이전에 만들어놓은 것들도 있어서 그랬던 것 같다. 그런데 거의 해쉬값으로 되어 있어서 이게 어떤 Docker-Volume인지도 알 수 없거니와 어떤 Docker-Volume이 사용중이고 사용중이지 않은지 지금 이름들만 봐서는 도저히 알 길이 없었다(사용중 = Docker-Volume에 파일같은 무언가가 있음, 사용중 X = Docker-Volume에 아무것도 없음) . 이러한 상황에 사용할 수 있는 것이 바로 docker volume prune이다. prune을 해석하면 ‘잘라내다, 없애다’ 라는 뜻이다.

$ docker volume prune

빨간색으로 표시된 부분들이 모두 사용되지 않는 Docker-Volume들이다. 위에 Deleted Volumes이라는 메시지와 함께 해당 Docker-Volume들을 싹 다 지워버린다.

또한 필자의 경우 Docker-Volume이 있는 경로(/var/lib/docker/volumes/)에서 docker volume prune 명령어를 입력했지만 꼭 Docker-Volume이 있는 경로일 필요는 없다. 어떤 경로에서 입력하더라도 똑같이 수행된다.

그러고 나서 Docker-Volume(/var/lib/docker/volumes/)의 경로로 가보면 사용 중인 Docker-Volume만 남아있음을 확인할 수 있다.



참고 사이트 :

  • https://dololak.tistory.com/404

阅读全文 »

Docker-Volume(2)
04 Dec 2018

저번 포스팅에서는 컨테이너를 띄울 때(docker run할 때) -v 옵션으로 Docker-Volume과 연동시키는 것까지 알아보았다. 이번 포스팅에서는 -v 옵션으로 호스트의 디렉토리와 연동시키는 것, volume container로 volume을 지정하는 방법에 대해 알아보고자 한다.

(이전 포스팅과 연결되는 내용이니 Docker-Volume(1) 포스팅을 읽고 와주세요!!)

  • 호스트 디렉토리를 volume으로 지정하는 경우

$ docker run -it -v [호스트 디렉토리]:[컨테이너 디렉토리] –rm [Docker image] /bin/bash

-it, –rm 옵션은 저번 포스팅에서 설명했으니 생략하겠다. -v 옵션으로 Docker-Volume을 연결했을 때와 똑같다. Docker-Volume 대신 volume으로 지정해 줄 호스트의 디렉토리를 써주면 된다. 이렇게 하면 컨테이너의 디렉토리가 호스트 디렉토리와 연동된다. 정확히는 [호스트 디렉토리]를 [컨테이너 디렉토리]에 mount 시키는 것이다. 하지만 Docker-Volume과 연동시켰을 때와 차이가 있다. 그 차이는 무엇인지 알아보자.

현재 /home/pooh/test11이 volume이 될 호스트의 디렉토리이다. 아무것도 없는 상태이다. 이제 -v 옵션으로 호스트 디렉토리와 연동시켜서 컨테이너를 띄워보자.

$ docker run -it -v /home/pooh/test11:/etc/mysql –rm mysql:5.7 /bin/bash

Docker-Volume과의 차이를 알겠는가? Docker-Volume(1) 포스팅에서 컨테이너 디렉토리와 비어 있는 Docker-Volume을 연동시켰을 때는 컨테이너의 /etc/mysql에 여러 파일이 있었는데 이번에는 비어 있는 호스트의 디렉토리와 컨테이너의 /etc/mysql연동시켰더니 아무 파일도 없다. 도대체 어떻게 된 일일까?

Docker-Volume(1) 포스팅에서 설명했지만 다시 설명하면, Docker-Volume과 연동시켜 -v 옵션으로 컨테이너를 띄울 때 역시 원래는 호스트에 있는 Docker-Volume이 해당 컨테이너의 디렉토리에 mount 되는 구조이다. 하지만 이렇게 비어 있는 Docker-Volume이 비어 있지 않은 컨테이너 디렉토리에 mount 되는 경우에는 컨테이너의 디렉토리에 있는 파일이나 하위 디렉토리가 비어 있는 Docker-Volume으로 복사된다. 물론 이렇게 한 번 복사가 되면(Docker-Volume에 파일이나 디렉토리같은 무언가가 있으면) 그때부터는 Docker-Volume에 있는 파일들이나 디렉토리들이 컨테이너의 디렉토리가 비어 있던 그렇지 않던 컨테이너의 디렉토리에 mount 된다.

하지만 Docker-Volume이 아닌 호스트 디렉토리와 연동시킨 경우는 호스트의 디렉토리가 비어 있어도 비어 있지 않은 컨테이너 디렉토리의 파일이나 디렉토리를 호스트의 디렉토리로 복사하지 않는다. 그냥 호스트의 디렉토리가 컨테이너 디렉토리(여기서는 /etc/mysql)로 mount 된다. 이렇게 호스트의 빈 디렉토리가 컨테이너 디렉토리의 파일들이 복사되지 않은 채로 mount 됐기 때문에 아무 파일이 없는 것이다. 그래도 이제 서로 연동이 된 상태이기 때문에 컨테이너에서 파일을 추가하던 호스트 디렉토리에서 파일을 추가하던 mount가 된 상태이기 때문에 호스트와 컨테이너에 똑같이 파일이 생성된다. 필자는 호스트에서 kkk.txt 파일을 생성해보겠다.

이제 컨테이너로 들어가서 /etc/mysql 디렉토리로 가보자.

똑같이 kkk.txt가 있다.

그렇다고 계속 저 상태는 아니다. 컨테이너를 빠져나와서(–rm 옵션을 줬기 때문에 exit만 해도 컨테이너가 삭제됨) 호스트 디렉토리와 연동시키지 않고(-v 옵션 빼고) 다시 새로 컨테이너를 실행시키면 해당 파일들이 다시 잘 나온다(단지, 호스트의 빈 디렉토리가 mount 돼서 아무 파일도 안 나온 것일 뿐 없어진 것이 아니다).

(Docker-Volume과 호스트 디렉토리의 차이가 좀 헷갈리 수 있습니다. 하지만, 직접 해보시면 금방 감이 오니까 직접 해보시는 걸 추천합니다!)

  • volume container를 volume으로 지정하는 경우

정확히는 volume container의 volume을 volume으로 지정하는 것이다. 이해를 돕기 위해 다음 그림을 보자.

volume container는 그림에서도 나와 있듯이 같은 volume(volume이 여러 개일수도 있음)을 여러 개의 컨테이너가 참조할 때 쓰면 좋다. 단, 이렇게 volume container의 volume을 참조하려면 이 volume container의 volume은 반드시 호스트 디렉토리와 연결되어 있는 volume이어야 한다. 직접 만들면서 이해해보자.

먼저 volume container를 만들어야 한다.

$ docker run –name volume_container -itd -v /home/pooh/host-volume1:/container-volume1 -v /home/pooh/host-volume2:/container-volume2 –rm centos

이렇게 volume-container가 만들어졌다. 이제 volume-conatiner에 container aaa와 container bbb를 붙여보자.(volume을 붙이려는 container 이름만 위 그림의 aaa, bbb와 같을 뿐 위의 그림처럼 volume container를 만들지는 X)

$ docker run –name=aaa –volumes-from=volume_container -it –rm ubuntu /bin/bash

이런 식으로 –volumes-from을 써주면 된다. volume_container는 계속 volume 역할을 할 수 있도록 -d 옵션으로 백그라운드에서 돌아가도록 했고 aaa, bbb 컨테이너는 눈으로 보기 위해서 백그라운드(-d 옵션)로 실행하지 않았지만 백그라운드로 실행해도 전혀 상관없다. 여튼 aaa 컨테이너에서 / 경로를 보면

container-volume1, container-volume2가 있다. 터미널을 하나 더 열어서 bbb 컨테이너도 확인해보자.

$ docker run –name=bbb –volumes-from=volume_container -it –rm ubuntu /bin/bash

역시나 있다. 즉, volume-container의 지정해 준 모든 volume이 mount 된다.

그럼 volume container의 volume을 위에서처럼 호스트의 디렉토리와 연결시키지 않고 그냥 컨테이너 디렉토리만 정의해주는 경우는 어떨까? 직접 해보면서 알아보자.

(컨테이너 이름들 잘 확인하면서 따라와주세요! 밑은 volume_test라는 이름의 volume container를 생성하는 과정이고 /container_volume_test는 컨테이너의 디렉토리입니다.)

$ docker run –name=volume_test -v /container_volume_test -itd –rm ubuntu

이렇게 한 다음 /container_volume_test에 kkk.txt 파일을 만들어보자.

이 상태에서 volume_test라는 이름의 volume container에 아까처럼 컨테이너를 붙여보자.

$ docker run –name=kkk –volumes-from=volume_test -it –rm centos /bin/bash

–volumes-from으로 volume container와 연결시켰더니 volume container의 volume에 따로 호스트 디렉토리를 연결시키지 않았음에도 불구하고 volume container의 volume이 잘 mount 되었음을 확인할 수 있다. 하지만, 지금 말한 것은 틀린 말이다. volume container의 volume(/container_volume_test/를 의미함)이 호스트의 디렉토리와 연결시키지 않은 것처럼 보이지만 사실은 저렇게 정의한 거 역시 호스트의 디렉토리와 연결이 된 상태이다. Docker-Volume (1) 포스팅에서 배웠던 Docker-Volume과 연결된 것이다. 물론 따로 Docker-Volume의 이름을 지정하지는 않았기 때문에 이름은 해쉬값으로 되어 있을 것이다. 그래도 한 번 확인해보자.

$ docker inspect –format=”” [container name]

해당 컨테이너에 대한 Docker-Volume이 생성되어 있음을 확인할 수 있고 역시나 해쉬값으로 되어 있다. 정리하면, Docker-Volume 역시 호스트의 디렉토리이므로 결국 호스트의 디렉토리와 연결이 돼서 저렇게 volume container로 쓸 수 있었던 것이다. 다시 말하지만 volume container에서 호스트의 디렉토리와 연결된 volume만 사용 가능하다.



참고 사이트 :

  • https://darkrasid.github.io/docker/container/volume/2017/05/10/docker-volumes.html https://m.blog.naver.com/PostView.nhn?blogId=alice_k106&logNo=220421203146&proxyReferer=https%3A%2F%2Fwww.google.co.kr%2F

阅读全文 »

Docker-Volume(1)
07 Nov 2018

이번 포스팅에서는 Docker-Volume에 대해서 다루고자 하는데 좀 길어져서 2번으로 나눠서 하려고 한다(너무 길어지면 읽기 싫어지니까…ㅎㅎ). 먼저 Docker-Volume이 무엇인지부터 알아보자.


  • Docker-Volume

: Docker가 관리해주는 볼륨으로 Docker로 컨테이너를 띄웠을 때 데이터를 유지시켜주는 역할을 한다. 컨테이너의 변경 상태를 저장하려면 이미지로 저장해야 하는데, 그럴 필요없이 필요한 부분(디렉토리)을 Docker-Volume과 연동시키면 컨테이너의 변경 사항이 Docker-Volume에 그대로 저장이 된다. 그래서, Container를 내렸다가 올리더라도 Docker-Volume에서 데이터들을 불러오기 때문에 저장된 상태가 유지된다. Docker-Volume의 경로는 /var/lib/docker/volumes/[Docker-Volume name]에 있고 저장된 데이터는 /var/lib/docker/volumes/[Docker-Volume명]/_data/에 있다.

docker volume을 확인하는 명령어는 다음과 같다.

$ docker volume ls

어떤 값은 이름으로 나오는 반면 어떤 값은 해쉬값으로 나온다. 왼쪽 local이라고 되어 있는 부분은 DRIVER, 오른쪽 값들은 ‘Docker-Volume name’이다(위에 잘라서 안 보이는데 VOLUME NAME이라고 나옴). 그런데, 이게 모든 Docker-Volume들을 나타내지 않는다는 말이 있는데, 어떤 Volume은 안 나오는 경우가 있다고 한다(저는 다 나왔습니다). 만약 자기가 Docker-Volume을 만들었는데 안 나온다면 위 경우에 해당한다고 보면 될 것 같다. 그럼 이런 경우 확인을 못하는 걸까? 아니다. Docker-Volume의 정보를 볼 수 있으면서 docker volume ls보다 좀 더 자세한 명령어가 있다.

$ docker volume inspect [Docker-Volume name]

물론 이 명령어는 하나의 Docker-Volume에 대해 자세하게 나오는 것이다. 만약 docker volume ls로 조회가 안 되는데 Docker-Volume의 이름을 알고 있다면 docker volume inspect 명령어로 만들어졌는지 확인하면 된다. 그림에서처럼 위는 우리가 알아볼 수 있는 Docker-Volume name인 반면 밑은 Docker-Volume name이 해쉬값으로 되어 있다. 어떤 경우에 Docker-Volume name이 해쉬값인지는 뒤에 나온다. 이제부터 Docker-Volume들이 Docker에서 어떻게 쓰일 수 있는지 알아보자.


  • Dockerfile에서 Docker-Volume을 volume으로 지정하는 경우

이는 dockerfile에서 Docker-Volume을 지정해주는 경우이다. 이를 해석해보면 mysql:5.7 이미지를 컨테이너로 실행시킬 때 /etc/mysql 디렉토리를 Docker-Volume과 연동시키겠다는 뜻이다. 이렇게 해주면 컨테이너가 내려졌다가 올라가더라도 다른 디렉토리들은 초기화가 되지만 /etc/mysql만큼은 Docker-Volume에 저장되어있는 데이터들이 불러와지기 때문에 저장된 상태가 유지된다.
(단, dockerfile에서의 VOLUME 명령어로는 Docker-Volume과만 연동될 뿐 호스트의 특정 디렉토리와는 연결할 수 X)
위 그림은 하나의 디렉토리만 지정했지만 VOLUME [“/etc/mysql”, “/var/lib/mysql”] 이런 식으로 컨테이너의 여러 디렉토리를 지정해 줄 수도 있다. 이렇게 여러 디렉토리를 지정해주면 Docker-Volume 역시 여러 개가 생성된다. 하지만 Docker-Volume의 이름을 지정하지 않았기 때문에 해쉬값으로 저장되어 알아보기가 힘들다. 그래서 관리 측면에서더 효율적이지 않다. 물론 어떤 해쉬값이 어떤 컨테이너의 Docker-Volume인지 찾을 수는 있다. 그건 바로 컨테이너의 이름이다. 다음 그림들을 보자.

$ docker build -t pooh:volume .

이렇게 dockerfile을 pooh:volume이라는 이름의 이미지로 빌드한다. 그 다음 컨테이너를 띄운다.

$ docker run -it –name=pooh_volume –rm pooh:volume /bin/bash

-it, –rm 옵션에 대해서 설명하자면 -it은 -i 옵션 + -t 옵션이 합쳐진 것으로

  • -i : 표준 입력(stdin)을 활성화하며 컨테이너와 연결(attach)되어 있지 않더라도 표준 입력을 유지해주는 옵션
  • -t : tty 즉, 콘솔이나 터미널이라고 생각하면 되는데, bash를 사용하려면 이 옵션을 반드시 설정해줘야 한다. 우리는 눈으로 확인하기 위해 bash를 이용할 것이므로 -t 옵션을 주었다.
  • -d : 여기에는 사용되지 않았지만 백그라운드로 돌려주는 옵션이다. 즉, -d 옵션을 주면 현재 화면은 호스트지만 백그라운드에서 컨테이너가 실행된다.

–rm 옵션은 해당 컨테이너를 나갔을 때(exit) 컨테이너를 자동으로 삭제시켜준다. –rm 옵션을 주지 않고 컨테이너를 띄우면 exit해도 컨테이너가 삭제되지 않는다.

현재 컨테이너의 /etc/mysql에 있는 파일들이다. 컨테이너를 띄웠으면 이제 컨테이너의 이름에 해당하는 볼륨을 볼 수 있다. 터미널을 하나 더 켜보자.

$ docker inspect [container name]

$ docker inspect pooh_volume

원래는 엄청나게 많은 내용이 나오지만 지금은 Docker-Volume이 어떻게 생성되었는지만 볼 것이기 때문에 “Mounts” 부분만 보면 된다. 또는 애초에 명령어를 “Mounts”만 나오게 할 수도 있다.

$ docker inspect –format=”” [container name]

$ docker inspect –format=”” pooh_volume

이 중에서 “Source” 부분이 경로인데 보면 해쉬값이 들어가 있는 것을 확인할 수 있다. 그럼 저 경로에 컨테이너의 /etc/mysql이 잘 mount 됐는지 확인해보자.

잘 mount 되어있다.

이렇게 dockerfile에서는 Docker-Volume의 이름을 지정할 수는 없고 만약 해쉬값이 아닌 이름으로 관리를 하고 싶다면 다른 방법을 이용해야 한다. 그 방법은 먼저 Docker-Volume을 만든 다음, 컨테이너를 띄울 때(docker run할 때) 만들어놓은 Docker-Volume과 연동시키는 것이다.


  • Docker-Volume을 만든 후 컨테이너를 띄울 때(docker run할 때) 만들어 놓은 Docker-Volume을 volume으로 지정하는 경우

$ docker volume create [Docker-Volume name]

(Docker-Volume 삭제는 create 대신 rm을 써주면 된다)

이렇게 하면 자신이 지은 이름(mysql_test)의 Docker-Volume을 생성한 것이다. 이렇게 하면 해쉬값일 때보다 알아보기가 쉬워 관리하기도 쉽다. 이 상태에서 컨테이너를 띄울 때(docker run 할 때) -v 옵션으로 방금 생성한 Docker-Volume과 컨테이너의 해당 경로를 연결시켜주면 된다. 사실 정확히는 Docker-Volume을 컨테이너 디렉토리에 mount 시키는 것이다.

$ docker run -it -v [Docker-Volume name]:[컨테이너 디렉토리] –rm [Docker image] /bin/bash

$ docker run -it -v mysql_test:/etc/mysql –rm mysql:5.7 /bin/bash

현재 컨테이너의 /etc/mysql에는 해당 파일들이 있다. 이 컨테이너의 /etc/mysql 경로에 pooh.txt 파일을 하나 추가해보자.

터미널을 하나 더 켜서 mysql_test라는 이름의 Docker-Volume으로 가보면

$ cd /var/lib/docker/volumes/mysql_test/_data/

mysql 컨테이너의 /etc/mysql에 있는 파일들이 똑같이 있다. 원래대로라면 Docker-Volume을 생성한 후 Docker-Volume에다가 파일을 추가하거나 그런 과정이 없었기 때문에 비어있는 상태이므로 빈 디렉토리가 컨테이너 디렉토리(/etc/mysql)에 mount되어야 하는데, Docker-Volume의 경우 비어있는 상태에서 컨테이너 디렉토리에 mount시키면 컨테이너 디렉토리에 파일이나 하위 디렉토리가 있다고 가정할 때 해당 파일이나 하위 디렉토리들을 Docker-Volume으로 그대로 복사한다. 하지만 Docker-Volume에 무언가가 있으면 Docker-Volume이 그대로 컨테이너 디렉토리로 mount된다. 예를 들어, Docker-Volume에 aaa.txt가 있고 컨테이너 디렉토리에 bbb.txt가 있다고 할 때 -v 옵션으로 둘을 연동시키면 컨테이너 디렉토리에서도 Docker-Volume이 mount 되기 때문에 bbb.txt는 보이지 않고 aaa.txt만 보이게 된다.

다시 돌아와서 컨테이너에 접속해있는 터미널로 가서 exit로 컨테이너를 빠져나가면 –rm 옵션을 줬기 때문에 컨테이너는 사라진다. 따라서, 원래는 Docker-Volume과 연동시키지 않았으면 다시 mysql 컨테이너를 띄웠을 때 아까 전에 mysql 컨테이너의 /etc/mysql에 새로 추가한 pooh.txt가 없어야 한다.

하지만, 다시 Docker-Volume과 연동시켜 컨테이너를 띄웠기 때문에 Docker-Volume에 저장된 데이터들을 불러와 pooh.txt가 있음을 확인할 수 있다. 좀 더 정확히 말하면, 아까 전에 Docker-Volume에 컨테이너 파일들이 복사됐기 때문에 이제 컨테이너와 연동시키면 해당 컨테이너 디렉토리에 mount가 되게 된다. 그래서, 원래는 컨테이너의 데이터들은 휘발성이기 때문에 컨테이너가 내려갔다가 다시 올라가면(띄워지면) 변경 사항들이 다 없어져야 하지만 이렇게 Docker-Volume을 사용하게 되면 변경 사항이 저장된다. 이게 Docker-Volume이 사용되는 이유다.

지금은 -v로 Docker-Volume과 컨테이너 디렉토리를 연동시켰지만 다음 포스팅에서는 호스트 디렉토리와 연동시키는 것에 대해서 알아볼 건데 Docker-Volume과 연동시켰을 때와 살짝 다르다. 일단 이번 포스팅은 여기서 마치겠다.




참고 사이트 :

  • https://darkrasid.github.io/docker/container/volume/2017/05/10/docker-volumes.html

阅读全文 »

ls -al 명령어의 파일 사이즈 쉽게 확인하기
01 Nov 2018

ls -al 명령어를 입력하면 해당 파일들의 자세한 정보들이 나온다. 이번 포스팅에서는 파일 사이즈에 대해서 다뤄보려고 한다.

빨간색으로 표시된 부분이 크기를 의미하는데 단위는 Byte이다. 하지만 이렇게 Byte 단위니까 얼마만큼 크기인지 직접 확인해보지 않는 이상 잘 보이지 않는다. 이때 -h 옵션을 이용하면 보기 쉽게 KB/MB/GB 단위로 바꿔준다. h는 human-readable(사람이 읽을 수 있는)이라는 뜻이다.

$ ls -alh

이렇게 딱 보기 쉽게 파일 사이즈가 나오는 것을 확인할 수 있다. 단위가 없는 파일들은 모두 Byte 단위이다. 여기에 -S 옵션까지 사용하면 사이즈가 큰 순서부터 차례대로 보여준다(즉, 내림차순).

$ ls -alSh




참고 사이트 :

  • http://faq.hostway.co.kr/index.php?document_srl=3799&mid=Linux_ETC&sort_index=regdate&order_type=desc

阅读全文 »

git push error - failed to push some refs to '원격 저장소 URL'
29 Oct 2018

저번 포스팅에서는 원격 저장소에 파일을 업로드하는 것까지 해봤다. 하지만 사실 처음부터 저렇게 한 번에 되지 않았다. 몇 가지 오류들이 있었는데, 그 부분을 지금 따로 다루기 위해서 이전 포스팅에서 다루지 않았다. 그 오류들에 대해서 다뤄보려고 한다.

일단 현재 상태는 commit까지 완료한 상태이다. 즉, 이 다음은 원격 저장소를 만들 차례인 것이다. 이전 포스팅과 마찬가지로 똑같이 원격 저장소를 만들어 주는데 이번에는 Initialize this repository with a README에 체크한 후 원격 저장소를 만들어보자(여기까지의 과정은 “git 기본 명령어 사용하기” 편을 참고해주세요!). 이전 포스팅에서도 설명했지만 Initialize this repository with a README에 체크하면 원격 저장소가 만들어짐과 동시에 README 파일이 하나 생성된다.

원격 저장소를 만들 때 단지 파일 하나를 생성하고 안하고의 차이인데 이거에 따라서 결과가 달라지나 싶었다. 하지만 완전히 달라지는 결과가 나왔다. 일단 현재는 README 파일과 함께 원격 저장소가 생성된 상태이다.

그럼 이제 git이 관리할 수 있도록 git에게 원격 저장소가 어디인지 알려줘야 한다. git remote add 명령어를 사용하자.

Initialize this repository with a README에 체크하지 않고 원격 저장소를 만들었을 때와 차이가 없다. 하지만 push하려고 하면

이전 포스팅과는 달리 push가 되지 않고 에러가 발생한다. 위 에러는 원격 저장소와 로컬 저장소의 상태가 달라서 나는 오류이다. 저번 포스팅을 떠올려보면 저번 포스팅에서는 로컬 저장소에도 아무것도 없었고 원격 저장소에도 아무것도 없는 상태였다. 그래서 둘의 상태가 같았기 때문에 push가 잘 됐던 것이다. 하지만, 이번 경우는 로컬 저장소에는 아무것도 없는 상태이지만 원격 저장소에는 README 파일이 있는 상태이다. 즉, 둘의 상태가 다르므로 오류가 발생한 것이다. 따라서, 둘의 상태를 같게 해줘야 한다. git pull 명령어로 로컬 저장소의 상태를 현재 원격 저장소의 상태로 만들어주자.

$ git pull [원격 저장소 닉네임] [브랜치]

로컬 컴퓨터에서 작업할 때, 원격 저장소의 최신 버전을 원하는 경우 이 명령어로 원격 저장소로부터 로컬 저장소로 변경사항을 다운받을 수 있다.

하지만 또 오류가 발생했다. 이 오류가 났을 때는 –allow-unrelated-histories를 뒤에 붙여주면 된다.

$ git pull [원격 저장소 닉네임] [브랜치] –allow-unrelated-histories

이 옵션은 이미 존재하는 두 프로젝트의 기록(history)를 저장하는 상황에 사용되는데, git에서는 서로 관련 기록이 없는 이질적인 두 프로젝트를 병합할 때 기본적으로 이를 거부한다고 한다. 그래서 –allow-unrelated-histories 옵션을 통해 이를 허용해주는 것이다.

이 명령어를 입력해주면 다음과 같은 화면이 나온다.

여기서는 리눅스에서 :wq 입력하는 것처럼 똑같이 :wq를 입력해서 저장하고 빠져나오면 된다.

그러면 README 파일이 로컬 저장소에 만들어졌다고 나온다(정확히는 원격 저장소에서 다운받았다). 직접 로컬 저장소에서 확인해보면

README 파일이 있는 것을 확인할 수 있다. 이제 다시 pooh.txt를 원격 저장소로 push해보자.

$ git push -u [원격 저장소 닉네임] [브랜치]

잘 push 되었다고 나온다. 원격 저장소로 직접 가서 확인해보면

pooh.txt 파일이 원격 저장소로 잘 업로드되었음을 확인할 수 있다.




참고 사이트 :

  • http://dh-dh.tistory.com/47
  • http://gdtbgl93.tistory.com/63
  • https://nolboo.kim/blog/2013/10/06/github-for-beginner/

阅读全文 »

검색

분야

사이트