지난 글에서는 Windows 10에 Hyper-V를 설치한뒤 여기에 가상컴퓨터를 만들어 CoreOS Install ISO 파일이 로딩되어 설치 Prompt 화면까지 보았다. 이번엔 여기까지 진행된 상황에서 CoreOS를 설치하는 과정을 진행하도록 하자.


CoreOS는 ISO 파일을 다운로드 받아 설치를 진행하지만 그 설치 과정에서 인터넷을 접속하여 설치와 관련된 파일을 다운로드 받아 진행하게 된다. 그래서 CoreOS 설치 Prompt 화면에서 네트워크가 이루어지도록 설정해야 할 필요성이 있다. 먼저 이 부분에 대한 내용을 설명하도록 하겠다.


네트워크를 잡기 위해서는 먼저 현재 Network Interface의 이름을 알아둘 필요가 있다. 다음의 명령을 실행해보자




ip addr 이란 명령어를 내리면 현재 설치된 가상컴퓨터의 Network Interface의 이름을 알게 되는데 lo는 Loopback Adapter 이고 eth0가 가상컴퓨터에 설치된 물리적인 Network Adapter 이다. 이 eth0가 우리가 네트워크를 설정해야 할 Network Interface가 된다. 


이제 이렇게 Network Interface의 이름을 알면 vi 에디터를 이용해서 다음의 파일을 작성하도록 한다


sudo vi /etc/systemd/network/static.network


위의 명령어로 vi 에디터가 열리면 다음의 내용을 입력하도록 한다


[Match]
Name=eth0

[Network]
Address=192.168.137.100/24
Gateway=192.168.137.1
DNS=8.8.8.8


Address 항목은 CoreOS에 설정할 IP이다. Address 항목에 설정한 IP 끝에 /24를 넣어줌으로써 Subnet Mask가 255.255.255.0이 된다. 근데 여기 내용을 보면 익숙한 IP가 보인다. 바로 Gateway로 설정된 192.168.137.1 이다. 이게 무슨 IP인가하면 이전 글에서 우리가 내부 가상 스위치를 만들면서 해당 가상 스위치에 설정된 IP가 바로 192.168.137.1이다. 그래서 CoreOS가 사용할 IP를 Gateway로 설정된 192.168.137.1과 같은 IP 영역대인 192.168.137.100을 설정함으로써 네트워크 통신이 이루어지도록 한다. 그리고 이 가상 스위치가 Windows 네트워크 어댑터와 통신을 하면서 인터넷 공유가 설정된 Windows 네트워크 어댑터를 통해 인터넷이 되도록 하는 것이다. 여기서는 CoreOS에 설정할 IP로 192.168.137.100을 사용했을뿐이지 반드시 이렇게 하라는 것이 아니다. 가상 스위치 IP인 192.168.137.1을 제외한 나머지 192.168.137.X IP이면 사용이 가능하다.


이렇게 static.network 파일을 만들면 다음의 명령을 이용해서 Network를 재시작 한다.


sudo systemctl restart systemd-networkd


이렇게 한 뒤에 ping을 이용해서 Window Host IP로 응답이 오는지 확인하고 위에서 DNS로 설정했던 8.8.8.8로도 응답이 오는지 확인한다. 8.8.8.8로 ping 명령을 내려서 응답이 오면 외부 인터넷과의 연결이 된다는 것을 의미한다(응답이 안올경우는 이 글의 마지막에 있는 주의사항을 보고 조치를 취하길 바란다).


ping을 통해 응답을 확인했으면 이제는 설치된 뒤의 계정을 만들 차례다. 다음과 같은 작업을 진행한다.



여기서 내릴 명령어는 sudo openssl passwd -1 > cloud-config.yaml 이다. 이 명령어 라인을 입력받으면 Password: 라고 나오면서 비밀번호를 요구하게 되는데 이때 비밀번호를 입력하고 Verifying - Password: 라고 나왔을때 위에서 입력한 비밀번호를 다시 한번 입력한다. 이런 과정을 거치면 vi나 cat을 이용해서 cloud-config.yaml 파일을 열어보았을때 입력한 비밀번호가 아닌 비밀번호를 암호화한 문자열이 나타난다.


이제 이렇게 만들어진 cloud-config.yaml을 편집할 차례이다. 다음의 명령어를 이용해서 cloud-config.yaml을 편집하자


sudo vi cloud-config.yaml


이 명령어를 실행하면 위에서 설명했다시피 입력한 패스워드가 암호화 된 문자열 한 줄만 있는 문서로 보이는데 이것을 다음과 같이 편집하도록 한다


#cloud-config
hostname: "coreos"
users:
- name: "terry"
  passwd: "$1$JAj어쩌구저쩌구..암호화된 문자열"
  groups:
    - "sudo"
    - "docker"


첫번째 줄은 #cloud-config로 입력한다. hostname은 CoreOS가 설치된 뒤의 hostname을 정하는 것으로 원하는 이름을 지정해주면 된다. name 항목은 계정명을 정하는 것으로 여기서는 terry로 사용했으며 passwd 항목에 위에서 만든 암호회된 문자열이 들어가게끔 한다. 애초에 이 파일을 열면 암호화된 문자열이 보이기 때문에 이 암호화된 문자열이 passwd: 뒤에 오게끔 문서를 편집하면 된다. groups 항목은 계정이 속할 group을 정하는 것으로 sudo와 docker를 지정하도록 한다(이 파일을 편집하기 전에 이 글의 마지막에 있는 주의사항을 읽기를 바란다).


이렇게 문서 편집을 마치면 다음의 명령을 이용해서 본격적으로 설치를 진행하도록 한다


sudo coreos-install -d /dev/sda -C stable -c cloud-config.yaml


이러면 Install 과정을 거쳐서 성공했다고 하는 메시지를 볼 수 있게 된다. 그런 메시지가 나오면 현재 보고 있는 가상컴퓨터 윈도우의 메뉴에서 미디어 -> DVD 드라이브->coreos_...꺼내기 메뉴를 선택하여 가상컴퓨터를 만들때 설정했던 CoreOS ISO 파일을 꺼내는 작업을 한 뒤에 다음의 명령을 내려서 재부팅이 되도록 한다.


sudo reboot


이렇게 재부팅을 하면 CoreOS 로그인 화면이 나오는데 그때 cloud-config.yaml을 만들때 사용했던 계정 이름과 비밀번호를 사용해서 로그인하면 된다.


지금까지 Windows Hyper-V에서 CoreOS를 설치하는 과정에 대해 설명했다. 마지막으로 CoreOS를 설치하면서 부딪쳤던 난관에 대해 정리한 주의사항을 정리하는 것으로 이 글을 마치도록 하겠다.




1. 위에서도 언급했다시피 CoreOS는 설치할때 인터넷이 되도록 설정되어 있어야 한다. 그래서 인터넷 연결이 되는지 확인해야 하는데 이때 사용하는 방법이 DNS 서버로 설정된 IP로 ping을 실행해서 응답이 오는지 확인하는 방법이다(DNS 서버로 통신이 되면 IP가 아닌 도메인으로 접속을 시도하는 것도 가능해지기 때문이다. 실제로 CoreOS는 설치시 자료를 받을때 도메인을 사용해서 자료를 받는다) 근데 ping을 실행해보면 응답이 안되는 경우가 많은데 이럴 경우 체크해야 할 부분이 방화벽이다. 방화벽에서 Hyper-V가 외부와 통신을 하는 것을 막는 경우가 있기 때문에 이런 부분에 대한 체크를 해야한다. 방화벽은 워낙 많은 프로그램이 있어서 여기서는 언급하기는 어려움을 양해해주기 바란다.


2. 무료로 배포되는 바이러스 백신의 경우엔 방화벽을 제공하지 않지만 상용으로 배포되는 바이러스 백신의 경우는 방화벽을 같이 배포하고 있다. 그런데 이렇게 상용으로 배포되는 방화벽의 기능을 끌 경우 컴퓨터에 방화벽이 아주 없어지는 것이 아니다. 상용으로 배포되는 방화벽 기능을 끄게 되면 자동으로 Windows 에서 제공하는 방화벽이 올라가기 때문에 상용으로 배포되는 방화벽 기능을 껐다고 해서 방화벽이 없다고 판단하면 안된다. 테스트를 하기 위해 상용으로 배포되는 방화벽을 껐다면 제어판에 들어가 Windows에서 제공하는 방화벽 기능이 현재 올라와 있는지 살펴보고 이것도 꺼야 방화벽 기능이 꺼졌다고 말할 수 있다.


3. 설치과정에서 네트워크 환경을 잡은것은 어디까지나 설치하기 위한 네트워크를 잡은 것이지 설치가 끝난 뒤의 네트워크 환경이 이루어지는 것은 아니다. 위에서 우리가 IP와 Gateway와 DNS를 잡았지만 그것은 어디까지나 설치하는 동안에 사용되는 것이지 설치가 된 뒤에 CoreOS가 우리가 설정한 내용으로 IP와 Gateway와 DNS가 설정되는 것은 아니라는 뜻이다. 설치가 된 뒤의 CoreOS의 네트워크 세팅은 아무것도 되어 있지가 않다. 그렇기땜에 설치가 된 뒤에 다시 위에서 진행했던 네트워크 셋팅 과정을 다시 한번 거쳐서 설치된 뒤의 CoreOS 네트워크 설정을 하도록 하자.


4. 설치가 다 마쳐서 인터넷이 되는것까지도 확인했는데도, 컴퓨터를 재부팅하면 CoreOS가 인터넷이 안되는 상황이 벌어진다. 네트워크 설정을 건드린것도 없었는데 안되어서 답답했었다. 가상 스위치도 ping이 되고 Windows Host ip로도 ping이 되는데 인터넷이 되질 않았다. 근데 이유를 보니 컴퓨터를 재부팅하면 이전 글에서 설명했던 Windows 네트워크 어댑터 공유 설정에서 원인이 있었다. 공유 설정이 되어 있는데도 재부팅을 하면 공유가 되지 않아서 인터넷이 안되는 그런 상황이 벌어졌다. 그래서 이럴 경우엔 공유 설정을 풀어서 확인 버튼을 클릭하며 공유 해제작업을 마친뒤 다시 공유 설정을 해서 확인 버튼을 클릭하면 정상적으로 동작한다. 이것은 비단 재부팅하는 상황뿐만이 아니라 위에서 설명했던 1,2번에서도 이 과정을 해봐야 한다. 이걸 해서 풀리는 경우도 있었다. 또한 컴퓨터에 전원을 넣고 켠 시점에서도 이 상황이 발생하기 때문에 전원을 켜서 부팅이 완료되면 공유 설정작업을 다시 진행해줘야 한다. 개인적으로 이 상황땜에 가상 컴퓨터를 몇번을 지우고 깔았는지 모를 정도로 가장 풀기 힘들었던 상황이었다.


5. cloud-config.yaml 파일을 만들때 users 항목의 name 항목을 통해 계정 이름을 정하게 되는데 이때 계정 이름으로 docker를 사용하면 안된다. 원래 CoreOS를 설치했던 가장 큰 이유는 docker 때문인지라 알기 쉽게 할려고 계정 이름과 패스워드를 docker로 했는데 설치는 이루어졌지만 설치된 뒤에 로그인 시 cloud-config.yaml 파일에 설정한 docker 계정과 해당 패스워드로 로그인을 할 수 없다. 이유는 CoreOS는 배포본 안에 docker 란 계정이 이미 존재하고 있어서 이와 같은 문제가 발생한 것이었다. 그래서 계정 이름으로 docker를 사용하면 안된다.


6. Hyper-V를 통해서 CoreOS 가상 컴퓨터를 시작한뒤 접속하면 화면에서 의미를 알 수 없는 문구들이 중간중간 나타나서 작업할때 불편한 것이 있다. 그래서 Hyper-V로는 CoreOS 가상 컴퓨터를 시작만 하고 접속은 putty를 이용해서 해당 가상 컴퓨터에 접속하면 편하다. 이때 프로토콜은 ssh를 사용하고 ip는 네트워크 설정과정에서 지정한 가상컴퓨터 ip를 사용하면 된다. 물론 포트번호는 ssh를 사용하기 때문에 22번을 사용한다

 


참고사이트 : Docker를 위한 CoreOS - Install




'프로그래밍 > Docker' 카테고리의 다른 글

Hyper-V에 CoreOS 설치하기(2)  (0) 2017.11.12
Hyper-V에 CoreOS 설치하기(1)  (0) 2017.11.12
docker에 대한 형식없는 정리  (0) 2017.07.19

트랙백을 확인할 수 있습니다

URL을 배껴둬서 트랙백을 보낼 수 있습니다

다른 카테고리의 글 목록

프로그래밍/Docker 카테고리의 포스트 목록을 보여줍니다

이번 글에서는 Windows에서 Docker를 사용하기 위한 첫번째 작업으로 Hyper-V에 CoreOS를 설치하는 작업을 설명해보고자 한다. Docker를 배포하는 Docker Inc. 에서는 원래 Windows 용으로 Docker for Windows를 배포한다. Docker for Windows 또한 Hyper-V에 MobyLinux를 설치해서 Docker를 운영한다. 근데 왜 CoreOS로 바꾸는가 하면 Docker용 Linux 컨테이너에서 systemctl 같은 서비스 관리 명령어를 사용하기 위해서였다(처음엔 이것을 하기 위해 Docker for Windows에서 해봤으나 기능이 되질 않아 CoreOS로 바꾸어서 결국 기능을 구현하긴 했지만 구현에 성공한 방법을 정작 Docker for Windows에서 해보지 않았기 때문에 Docker for Windows에서도 구현될 수도 있을 가능성이 있음을 미리 밝혀둔다).


먼저 Hyper-V를 설치하도록 한다. Docker for Windows의 경우 Windows 10의 빌드번호가 10586 이상이어야 가능하다. 그래서 본인의 Windows 10 빌드번호를 먼저 확인하기 바란다(Windows 10 Anniversary Update가 적용된 버전이면 이 빌드번호가 된다. 검색해보면 기존의 Windows 10 에서 Anniversary Update로 업그레이드할 경우 동작이 되지 않는다는 내용도 있어서 진행해보고 안될 경우 아예 클린방식으로 새로이 업그레이드된 버전으로 설치해보길 바란다) Windows 10의 제어판->프로그램 및 기능에 들어가서 해당 화면의 왼쪽에 있는 Windows 기능 켜기/끄기를 선택하면 아래와 같은 창이 나오는데 여기에서 Hyper-V 항목을 찾아 다음과 같이 체크한뒤 확인 버튼을 클릭하면 Hyper-V 설치를 마치게 된다.






Hyper-V를 설치하면 Windows 10에 다음과 같이 Windows 관리도구로 Hyper-V가 새로이 추가된다




이제 메뉴에서 Hyper-V 관리자를 클릭하면 다음의 화면이 나타난다.




이 화면에서 이제 CoreOS가 설치될 가상 컴퓨터를 설치해야 한다. 근데 그 전에 해야 할 것이 있다. 바로 가상 스위치를 만들어야 한다. 이것의 역할은 Windows 10과 가상 컴퓨터와의 네트워크를 중간에서 이어주는 역할을 하게 된다. 그래서 이제 이 가상 스위치를 만들어보도록 하자. Hyper-V 관리자 화면의 오른쪽을 보면 가상 스위치 관리자 란 항목이 있는데 이것을 클릭하면 다음의 화면이 나타난다.




이 화면에서 가상 스위치 유형을 내부로 선택한뒤 가상 스위치 만들기 버튼을 클릭하면 다음의 화면이 나타난다




이름 항목은 적당한 이름을 주고(여기서는 NAT로 주었다. 실제 NAT 역할을 하기땜에..) 이전 화면에서 가상 스위치 유형을 내부로 설정했기 때문에 연결형식은 자동으로 내부 네트워크로 설정되어 있다. 이런 상태에서 확인 버튼을 클릭해준다. 그러면 NAT라는 이름의 가상 스위치가 생성이 된다. 이렇게 생성된 가상 스위치는 제어판 -> 네트워크 및 공유 센터 화면에서 화면 왼쪽에 있는 어댑터 설정 변경을 클릭하면 다음과 같이 나타나게 된다.




이제 Windows 10에서 사용중인 네트워크 연결(각자 사용하는 PC에서는 이름이 다르겠지만 여기서는 위의 화면을 기준으로 이더넷으로 하겠다)을 공유해야 한다. 이더넷에서 마우스 우클릭해서 속성을 들어간뒤 공유 탭을 클릭하면 다음의 화면이 나타난다. 여기에서 첫번째 항목인 다른 네트워크 사용자가 이 컴퓨터의 인터넷 연결을 통해 연결할 수 있도록 허용(N) 항목을 체크하고 아래에 있는 다른 네트워크 사용자가 공유 인터넷 연결을 제어하거나 중지시킬 수 있도록 허용(O) 항목은 체크해제 하도록 한다(지금은 네트워크 연결이 2개뿐이 없어서 이렇게 나오지만 노트북에서 진행할 경우 무선 어댑터가 있기 때문에 네트워크 연결이 3개가 된다. 네트워크 연결이 3개 이상이 되면 첫번째 항목에서 공유할 네트워크 연결을 선택할 콤보박스가 나오는데 이때 vEthernet(NAT)를 선택해주면 된다) 확인 버튼을 클릭하면 다음과 같은 대화상자가 나오는데 여기에서 예를 눌러준다. 그러면 vEthernet(NAT)는 IP가 192.168.137.1을 갖게 된다. 






이쯤에서 이렇게 하는 이유에 대해 간단히 언급하겠다. 위에서 가상 스위치 유형을 만들때 가상 스위치 유형을 내부로 지정해서 만들었다. 이 유형에는 외부, 내부, 개인 이렇게 3가지가 있는데 외부는 Host 컴퓨터(여기서는 Windows 10)의 네트워크 영역대를 그대로 이용하게 된다. 예를 들어 Windows 10의 IP가 192.168.0.17이면 외부는 192.168.0.100 같이 같은 네트워크 영역대를 사용하면서 Host 컴퓨터 뿐만 아니라 Host 컴퓨터와 같은 영역대의 컴퓨터와 위에서 언급한 별도의 공유 절차 없이 통신을 할 수 있게 된다. 내부는 외부와는 달리 다른 네트워크 영역대(위에서 설정하게 된 192.168.137.1 같은 전혀 다른 네트워크 영역대)를 갖게 된다. Host 컴퓨터와는 통신이 되지만 Host 컴퓨터와 같은 네트워크 영역대의 컴퓨터와는 통신이 이루어지지 않는다. 정리하면 192.168.137.X대의 독자적인 네트워크 영역을 구축한다고 보면 된다. 외부로 할 경우엔 가상 컴퓨터가 Host 컴퓨터와 같은 영역대의 IP를 사용하기 때문에 네트워크의 부담이 줄어드는 장점이 있지만 노트북 같이 이동하는 상황이 잦아서 그에 따른 네트워크 IP가 유동적으로 바뀌어야 하는 경우 이에 대한 IP를 일일이 수정해야 하는 불편함이 있다. 내부의 경우는 이 가상 스위치를 통해 이 스위치로 설정된 모든 가상 컴퓨터와 네트워크 자원을 공유해서 네트워크의 퍼포먼스는 떨어지지만 이동하는 상황이 잦은 경우 내부는 독자적인 네트워크 이므로 IP를 수정할 필요가 없다. 그래서 외부 스위치는 운영서버 같이 네트워크 IP가 고정적이고 네트워크 자원을 독점해서 사용해야 하는 환경에서 좋고 내부 스위치는 개발 노트북 같이 네트워크 IP가 유동적이고 네트워크 자원을 공유해야 사용해야 하는 환경에서 좋다.


가상 스위치 만드는 작업을 마쳤으면 이제 가상 컴퓨터를 만들어보도록 하자. Hyper-V 관리자 화면에서 오른쪽 메뉴를 보면 새로 만들기 란 항목이 있는데 이것을 클릭하면 조그만 팝업 메뉴가 나타난다. 여기서 가상 컴퓨터를 선택하면 다음과 같은 화면이 나타난다. 이 화면에서 다음을 눌러 진행한다.




이름 및 위치 지정 화면에서 적당한 이름을 준다. 만약 가상 컴퓨터를 다른 위치에 저장하려 할 경우엔 다음 화면과 같이 가상 컴퓨터를 다른 위치에 저장 항목을 체크한뒤 활성화 되는 찾아보기 버튼을 클릭해서 해당 폴더를 지정해주면 된다. 이 화면에서 다음을 눌러 진행한다.



세대 지정 화면에서는 1세대를 선택한뒤 다음을 눌러 진행한다.




메모리 할당은 자신의 컴퓨터 메모리를 고려해서 적당하게 지정해준다. 여기서는 4기가(4096 MB)를 설정했는데 컴퓨터의 물리 메모리가 32기가라 4기가로 설정한 것이지 모든 환경에서 이렇게 하라는 것이 아니다. 이 화면에서 다음을 눌러 진행한다




네트워크 구성 화면에서는 연결을 선택해줘야 하는데 이때 위에서 만들었던 내부 가상스위치(여기서는 NAT로 만들었기 때문에 NAT를 선택한다)를 선택해주도록 한다. 이 화면에서 다음을 눌러 진행한다.




가상 하드 디스크 연결 화면에서는 현재 만들고자 하는 가상 컴퓨터의 가상 하드 디스크를 만들게 되는데 이름과 위치는 건드릴 필요는 없고 크기를 지정해야 한다. 이때 10 GB 이상은 되어야 한다. 이렇게 한 이유가 있는데 밑에서 바로 언급하겠지만 CoreOS의 설치 용량을 몰라서 CoreOS의 인스톨 ISO를 보고 판단하게 되었다. CoreOS의 Install ISO 파일이 300 MB도 안되어서 4GB로 주어서 진행했었는데 가상 컴퓨터를 만드는데는 문제가 없었으나 CoreOS Install에는 실패했었다. 그래서 다시 가상 컴퓨터를 만들어서 이 용량을 10 GB로 주니 문제없이 해결이 되었다. 나는 여유가 있어서 40 GB로 주었다. 40 GB로 주어도 처음에 이 용량을 40 GB로 만들고 시작하진 않는다. Docker Hub를 통해 배포되는 이미지가 일반적으로 500 MB가 넘는것이 드물지만 이런 이미지를 여러개 갖고 있게 되며 이 이미지가 컨테이너로 올라갈 경우 필요에 따라 파일을 CoreOS에서 관리해야 할 필요성도 있어서 40 GB로 좀 여유있게 주었다. 이 화면에서 다음을 눌러 진행한다.



설치옵션 화면에서는 부팅 가능 CD/DVD-ROM에서 운영 체제 설치(C) 항목을 선택한 뒤 이미지 파일(.iso)(I) 항목을 선택하고 CoreOS Install ISO 파일을 지정해주면 된다. CoreOS Install ISO 파일은 https://coreos.com/os/docs/latest/booting-with-iso.html 에서 Stable Channel 탭에서 Download Stable ISO 버튼을 클릭하면 다운로드 받을 수 있다. 이 화면에서 다음을 눌러 진행한다.




요약 화면에서는 지금까지 설정한 항목들에 대한 내용들을 최종적으로 보여주게 된다. 여기서 마침 버튼을 누르면 가상 컴퓨터를 만들게 되며 Hyper-V 관리자 화면에서 방금 만들어진 가상 컴퓨터가 보이게 된다.




이렇게 보이는 가상 컴퓨터(여기서는 CoreOS) 항목을 마우스 우클릭을 하면 팝업 메뉴가 나타나는데 여기서 연결을 선택한다. 연결을 선택하면 다음 화면과 같이 별도의 새 창이 나타난다. 이것은 비유하면 아직 전원이 들어오지 않은 컴퓨터라 여기면 된다. 


이 화면에서 녹색으로 된 동그란 모양의 시작 버튼을 누르거나 화면에서 안내해주듯이 시작을 선택하면 가상 컴퓨터를 만들면서 설정했던 CoreOS Install ISO 파일로 부팅을 하면서 가상 컴퓨터기 기동을 하게 되어 다음과 같이 보이게 된다.




오해를 할까봐 하는 말인데 이 화면은 CoreOS 가 설치가 마쳐진 뒤에 나오는 화면이 아니다. Windows 설치 과정으로 비유하면 우리가 Windows Install USB 디스크를 컴퓨터에 꽃은뒤 전원을 켜서 USB로 부팅하면 Windows 설치 화면을 보여주는데 이런 Windows 설치 화면과 같은 개념의 화면이 이 화면이라고 보면 된다. CoreOS는 명령어를 이용해서 설치하는 작업을 거치기 때문에 이런 Text 기반의 Prompt 화면으로 보여지게 되는 것이다. 이 화면에서 중간중간에 이상한 문구들이 나타나지만 이런것들은 무시하면 된다.


이번 글에서는 Hyper-V 설치 및 CoreOS를 설치하기 위한 가상 컴퓨터 생성에 대해 알아보았다. 다음 글에서는 이렇게 나온 CoreOS 설치 화면에서 진행해야 하는 CoreOS 설치에 대해 알아보도록 하겠다.



'프로그래밍 > Docker' 카테고리의 다른 글

Hyper-V에 CoreOS 설치하기(2)  (0) 2017.11.12
Hyper-V에 CoreOS 설치하기(1)  (0) 2017.11.12
docker에 대한 형식없는 정리  (0) 2017.07.19

트랙백을 확인할 수 있습니다

URL을 배껴둬서 트랙백을 보낼 수 있습니다

다른 카테고리의 글 목록

프로그래밍/Docker 카테고리의 포스트 목록을 보여줍니다

집에서 사용하는 PC에서 헤드셋이 연결되어 있질 않아 밤에 음악이나 게임을 할때 불편한 점이 있었다. 그래서 게이밍 헤드셋을 알아보던중 한성컴퓨터에서 요근래 새로이 나온 게이밍헤드셋으로 GTune HS60 7.1 ch LED 게이밍헤드셋이 나와서 이 모델로 구입하게 되었다(내가 구입하던 시점에서 한성컴퓨터가 이 모델의 가격을 5000원 정도 할인한 상태로 판매하고 있어서 앱코 모델과 가격 차이가 별로 있지를 않아서 이 모델로 구입했다) 옥션에서 구매했지만 실제로는 한성컴퓨터가 옥션을 통해 파는 것이기 때문에 한성컴퓨터에서 구매했다고 보면 될 듯 하다. 이 제품은 항상 내 돈을 지불하고 쓴 사용기임을 밝혀둔다. 그런 의미에서 구매내역을 올린다.



옥션에서 구매하고 그 다음날 집으로 배송이 왔다. 포장상태는 정말 양호했다.




한성컴퓨터 제품 관련 사용기를 보면서 만족하던것 중 하나는 제품의 포장상태였다. 역시 이 제품 또한 포장 상태는 정말이지 양호했다. 사진을 보면 알겠지만 제품박스가 완충제와 함께 별도로 큰 박스에 포장되어 왔다. 제품 크기도 조금 있어서인지 제품 박스도 큰 편이었다. 사진을 별도로 찍지는 않았지만 이 제품은 USB 포트를 사용하는 제품이다. 그러나 금도금은 되어 있지 않기 때문에 혹시나 금도금 여부를 구매의 포인트로 삼고 있는 사람이 있다면 알아두기를 바란다.


제품 내용물은 헤드셋과 사용서 및 제품보증서 역할을 하는 종이(책자 형태가 아닌 종이 1장으로 되어 있어서 종이란 표현을 썼다)가 들어 있다.



USB 포트에 제품을 연결하면 자동으로 인식이 되며 특별한 드라이버를 요구하지는 않는다. 컴퓨터에 연결하면 윈도우 장치관리자에서 다음과 같이 인식이 된다.



사운드, 비디오 및 게임 컨트롤러 항목에서 USB Audio Device로 인식이 되며 오디오 입력 및 출력에서는 스피커(USB Audio Device)와 마이크(USB Audio Device)로 인식이 된다.


그러나 이 상태로는 가상 7.1채널이 자동으로 지원이 되는 것이 아니기 때문에 이를 사용하려면 한성컴퓨터 홈페이지 자료실에 가서 이 제품에 대한 가상 드라이버를 다운로드 받아 설치하면 된다. 드라이버를 다운로드 받을때 사용설명서를 pdf 문서로 같이 제공하기 때문에 이를 다운로드 받아 이대로 설정하면 7.1 채널을 설정할 수 있다. 그 내용은 생략하고 그와는 별도로 윈도우에서 해줘야 할 설정을 얘기하도록 하겠다. 


제어판->소리 를 가면 다음과 같은 화면이 나온다.



위와 같은 화면에서 스피커(USB Audio Device)를 선택한 상태에서 속성 버튼을 클릭한다. 그러면 아래와 같은 스피커 속성 화면이 나타나는데 이 상태에서 공간 음향 탭을 클릭하면 다음과 같은 화면이 나타난다.



이 상태에서 공간 음향 형식을 헤드폰용 Windows Sonic을 선택하고 7.1 가상 서라운드 사운드 켜기 체크항목을 체크한 뒤 확인 버튼을 눌러 윈도우에서의 가상 7.1 채널 설정 작업을 완료하도록 한다.


컴퓨터와 연결한 뒤 전원을 올리면 LED 제품 답게 주황색 LED 빛이 나타나는 것을 볼 수 있다. 다음의 사진은 헤드셋의 LED에 빛이 들어온 상태이다.



헤드셋 왼쪽에는 마이크가 달려 있으며 마이크는 헤드셋 안으로 들어가는 타입은 아니지만 원하는 부분으로 자유자재로 꺾는것이 가능하다. 그리고 VIBRATION 옆에 있는 버튼을 누르는것으로 진동 기능을 동작시키거나 중지시킬수 있다.



헤드셋 오른쪽으로는 제품 로고가 붙어있다.



헤드셋을 머리에 썼을때 머리에 닿는 부분은 2중 구조로 되어 있다. 맨 바깥쪽은 얖은 철판 2개로 구성되어 있고 머리가 직접적으로 닿는 부분은 플라스틱 판 2개를 감싼 천(?)으로 되어 있다. 자신의 머리 크기에 맞춰 능동적으로 헤드셋 크기를 조절하는 것은 없지만 이 천으로 감싼 부분이 자동으로 늘어나면서 머리 크기에 맞춰지도록 되어 있다.



헤드셋의 직접적인 크기 비교를 위해 개인적으로 가지고 있는 소니 블루투스 헤드셋과 나란히 놓고 찍은 사진이다. 소니 헤드셋은 내 머리 크기에 맞춰서 조정을 해놓은 상태인데 내 머리 상태에 맞는 소니것보다는 큰 사이즈이다(이것을 보여주는 이유는 나중에 헤드셋 장단점을 설명할때 사용되기 위함이니 관심있는 사람은 잘 보기 바란다)



아마 이 글을 보는 독자들이 궁금해 할 헤드셋 장단점에 대해 얘기하도록 하겠다. 개인적으로 막귀라는 것을 미리 밝혀두고 글을 쓰도록 하겠다. 소리라는게 사진이나 동영상으로 보여줄 수 있는 것은 아니기 땜에 어디까지나 개인적인 소견임을 말해두고 시작하겠다.


음질에 대해서는 딱히 문제를 삼을게 없을 정도로 큰 문제는 없었다. 예를 들어 좀 먹은 소리가 난다거나 미세하게 잡음이 있는 그런 것은 없었다. 하지만 그렇다고 맑은 느낌이 나는 것도 아니었다. 위의 사진에서 보여줬던 소니 헤드셋의 경우 중저음 강화 기능이 있어서 중저음은 무겁게 둥둥 치는 느낌이 나기 때문에 중저음과 중저음이 아닌것이 확연히 구분이 되지만 이 헤드셋은 그런 기능은 제공되지 않기 때문에 중저음의 비트 위주의 음악을 좋아하는 사람에게는 그리 메리트는 없어보일듯 하다. 음질은 걍 무난하다고 보면 될듯 하다.


7.1 채널의 경우는 오버워치로 테스트 해봤는데 게임할때 정신이 없어서 7.1이 되는지를 제대로 살펴보지 못한것도 있지만 머랄까..방향을 알수 있다거나 하는 그런 느낌은 받지 못했다(오버워치에서는 원래 2채널을 가상 7.1채널로 해주는 옵션이 있긴 한데 이 옵션을 끈 상태에서 진행했는데도 그러했다) 7.1 채널이 지원되는 게임에서만 할 수 있는건지를 몰라서 다른 게임으로 테스트를 해보기도 뭣하고 이 부분에 대해서는 좀 호불호가 갈릴 부분이 있을듯 하다. 오버워치 같이 정신없이 싸우는 그런 스타일의 게임보다는 배틀그라운드 같이 조금은 정신을 챙길수 있는 그런 게임에서 테스트를 해보는게 맞을듯 하다(개인적으로 이 게임이 없어서 이걸로 테스트를 해보지는 못했다)


대신 음악에서는 7.1채널의 느낌이 나기는 했다. 한성컴퓨터에서 제공하는 드라이버 소프트웨어에서 사용되는 기능을 이용해서 테스트를 해보았는데 명확하게 7.1채널의 느낌이 난다기엔 좀 머랄까..소리가 제대로 분리되는 그런 느낌이 들지는 못했다(방향성에서 몇군데서 좀 뭉개는 느낌이랄까..)


다음으로 크기를 말하고 싶은데 위에서 언급했다시피 소니 블루투스 헤드셋보다도 조금 더 큰 사이즈이다. 때문에 머리가 작은 사람에게는 불편함이 있을수도 있다(실제로 옥션에서 자신의 머리가 작아 헤드셋이 흘러 내려 이로 인해 반품 신청한 사람의 글을 본 것이 있다.) 머리를 눌르지 않아 편안한 감은 있지만 개인적으로는 머리 위에 밀착이 되어야 안정감이 있어서 밀착을 조금은 선호하는 편이다. 그러다보니 머리에 밀착이 된다기 보단 머리위에 걸치는 그런 느낌이어서 개인적으로 착용감에서는 아쉬움이 있었다(이것은 내가 머리가 작아서이지 머리가 큰 사람일 경우엔 밀착이 되는 느낌을 가질수도 있다. 위에서 얘기했다시피 머리 크기에 따라 자동으로 조절이 되기 때문에 그게 가능하다)


장점보다는 단점 위주로 글을 썼는데 일단 시중의 글들을 읽어보면 7.1 채널은 가상보다는 리얼로 가는 것이 확실하다는 의견이 많다. 그래서 7.1 채널을 위주로 선택하는 사람이라면 머 입문용으로 산다면 말리진 않겠으나 제대로 느끼고 싶은 사람에게는 좋은 제품은 아닐듯 하다. 다만 가성비 차원에서 보면 나쁘지는 않은 가격이다(이거보다 낮은 가격으로 앱코 제품이 있기는 한데 앱코것과 비교해서 선택하는것도 나쁘지는 않을듯 하다. 나는 이벤트땜에 할인된 가격에 사서 앱코랑 별 차이라 안났지만 현재는 이벤트가 종료되었기땜에 앱코보다는 비싸다) 그러나 완성도에 있어서는 괜찮은 점수를 주고 싶다(5점 만점에 4점 정도?) 나는 7.1 보다는 밤에 편하게 게임하고 음악 감상하는 용도로 기왕이면 7.1 채널을 느껴보고 싶어서 산 제품인지라 딱히 이러한 단점을 느껴도 비추할 정도까지는 아니지만 7.1 채널을 제대로 느끼고 싶은 사람이라면 돈을 좀더 투자해서 다른걸 사는게 나을듯 하다. 그리고 머리가 작은 사람에게는 좀 헐렁할 수도 있으니 여러 사용기를 읽어보고 판단했음 한다. 적당한 가격으로 사기에는 무난하며 완성도도 높은 제품이지만 개개인마다 선호하는 부분이 다르기 때문에 이 부분에 대해서는 좀더 잘 살펴보고 구매를 했으면 한다.


* 2017년 12월 6일 추가


1주일 전쯤 지인의 성화(?)에 못이겨 배틀그라운드를 구매했다. 위의 글에서도 잠깐 언급했지만 게임으로는 오버워치만 테스트해봤기때문에 7.1 채널에 대한 확실한 지원 느낌을 갖기가 어려웠다. 그래서 배틀그라운드로 진행해보았는데 여기서는 7.1 채널의 느낌이 확실히 살아났다. 소리의 방향성이 느껴졌다. 심지어 건물안에서도 소리에 대한 방향의 느낌도 가질수 있었는데 예를 들어 건물 밖에서 자동차가 다니는 소리나 또는 사람이 건물 아래층을 걸어다닐때의 소리에 대한 방향성을 느낄수 있었다. 마이크를 통한 음성 대화에 대해서도 문제가 없었다. 지인과 게임 플레이를 할때 배틀그라운드가 제공하는 음성대화가 아닌 디스코드를 이용해서 진행해 보았는데 딱히 문제점은 없었다. 내 음성이 상대에게 문제없이 잘 전달되었고 상대의 음성또한 나에게 잘 전달되었다. 배틀그라운드를 위해 이 헤드셋을 구입한다면 이 헤드셋은 좋은 선택이 될 수 있다.

트랙백을 확인할 수 있습니다

URL을 배껴둬서 트랙백을 보낼 수 있습니다

다른 카테고리의 글 목록

사는 얘기/나의 흔적 카테고리의 포스트 목록을 보여줍니다

docker 공부하면서 case by case로 체계없이 정리한 것들을 기록한 것들이다.

이 내용들은 늘어나거나 줄어들거나 수정될 수 있다는 것을 미리 말해둔다

말그대로 docker를 공부하면서 알게된 단편 지식들을 보관 차원에서 적어둔 것이기 때문이다


1. docker hub에서 이미지를 받을때는 pull 명령을 사용한다. 예를 들어 wildfly의 최신버전(latest)를 받을 경우 다음과 같이 한다.


docker pull jboss/wildfly:latest


2. 내가 받은 이미지들의 목록을 볼 경우 다음과 같이 한다


docker images


3. 이미지 세부 정보를 확인할 때는 inspect 명령어를 사용한다.


docker inspect jboss/wildfly:latest


세부 정보는 json 문자열 형태로 보여지며 주요 정보로는 이미지 ID, 생성일, Docker 버전, 이미지 생성자, CPU 등을 제공한다

정보가 json 문자열 형태로 길게 나오기때문에 만약 특정 정보를 보고자 할때는 다음과 같이 format 옵션을 주어 보고자 하는 항목을 지정하면 그 항목에 대해서만 볼 수 있다. 예를 들어


docker inspect --format="{{ .Os}}" jboss/wildfly:latest


를 사용하면 Os 항목에 대한 값만 알 수 있다. 또 Config 항목의 하위 항목으로 있는 Hostname 항목 값을 알고자 할때는 다음과 같이 한다


docker inspect --format="{{ .Config.Hostname}}" jboss/wildfly:latest


이것은 우리가 json 문자열을 객체로 만들었을때 접근하는 방법을 생각하며 이 명령을 사용하면 된다


4. 이미지를 삭제할때는 다음과 같이 한다


docker rmi jboss/wildfly:latest


5. docker 이미지를 받았으면 이제 이 이미지를 가지고 하나의 컨테이너를 생성해서 실행시키도록 한다. 이해하기 쉽게끔 설명하자면 프로그래밍에서 얘기하는 클래스와 객체로 설명하면 이해하기 쉬울듯 하다.


A라는 클래스를 이용해서 객체를 만들때..


A b = new A();

A c = new A();


이렇게 만들것이다. A라는 클래스를 이용해서 만든 객체 b와 c가 있지만 이 b와 c는 서로를 간섭하지는 않는다. 이것을 docker에 비춰보면 클래스는 이미지가 되고 객체는 컨테이너가 된다. 필요성에 따라 이미지를 이용해서 0개 이상의 컨테이너를 만들수 있지만 이렇게 만들어진 컨테이너들은 서로 독립적인 공간이 되어 서로 간섭하지를 않게 된다


컨테이너의 라이프 사이클은 docker 명령어를 빌려서 설명을 하자면 create(생성) -> start(시작) -> stop(중지) -> rm(삭제) 개념으로 흘러가며 create와 start를 같이 해주는 명령어인 run이 있고 start인 상태에서 중지했다가 다시 시작하는 명령어로 restart가 있다


6. docker에서 컨테이너를 생성하면서 동시에 시작할때는 run을 사용한다. wildfly를 예로 들자면 다음과 같이 한다


docker run -it --name "wildfly" -p 8080:8080 jboss/wildfly:latest


run 명령어를 사용하면서 같이 사용된 옵션에 대해 설명을 하자면 


-i 옵션은 컨테이너 표준 입력을 연다는 뜻이고, -t는 tty(단말 디바이스)를 사용한다는 의미이다. 이 둘을 묶어서 -it로 사용한 것이다. 


--name 옵션을 주면 해당 컨테이너에 대해 특별한 이름을 부여하는 옵션이다. 컨테이너를 start 명령어로 시작하거나 stop 명령어를 이용해서 종료할때 대상 컨테이너를 지정하기 위해 컨테이너 ID를 입력해야 하는데 이 ID라는게 의미가 없는 숫자/문자가 조합된 문자열이라 타이핑하기 어렵다. 이러한 상황을 좀더 쉽게 사용하게 하기 위해 --name 옵션을 주어 의미있는 문자열을 지정함으로써 차후에 start, stop 명령어를 사용할때 그 문자열을 사용하여 해당 명령어를 쉽게 실행할 수 있다.


-p는 호스트와 컨테이너 간의 포트를 연결하는 옵션이다. wildfly는 8080 포트를 이용해서 통신하게 되는데 이것은 어디까지나 컨테이너의 8080 포트를 열은 것이기 때문에 우리가 테스트하기위해 브라우저에서 http://localhost:8080을 입력해도 동작이 이루어지지 않는다. 이로 인해 호스트의 8080 포트를 컨테이너의 8080 포트와 연결해야 제대로 된 동작을 할 수 있다.  한가지 더 첨언을 하자면 컨테이너가 8080 포트를 열었다고 해서 호스트도 반드시 8080 포트를 열으라는 법은 없다. 예를 들어 wildfly 컨테이너를 2개 이상 운영하는데 두 컨테이너가 모두 8080 포트를 열어도 문제가 되는 것은 없다. 그러나 이 두 포트를 모두 호스트의 8080 포트에 연결할 수는 없다. 즉 둘 중 하나의 컨테이너는 -p 8081:8080 이런 식으로 호스트의 8081 포트를 컨테이너의 8080 포트로 열어서 동작하게끔 해야한다


7. 6번의 과정으로 실행을 하게 되면 docker의 foreground로 실행하는 것이기 때문에 이런 식으로의 실행은 추천하지 않는다.  즉 다른 컨테이너를 시작할려면 다시 쉘 창을 열어서 docker 관련 명령을 실행해야 하기 때문이다. 대신 foreground에서 실행시키는 것이기 때문에 컨테이너를 중지할려면 ctrl-c를 눌러 중지할 수 있으며 관련 콘솔 로그 내용도 바로 확인 할 수 있는 장점은 있다. 그러나 docker로 실행되는 것이 WAS나 DB 서버 같은 서버용 프로그램인것을 감안하면 background로 실행되는 것이 좋다


8. 7번에서 설명한대로 background로 컨테이너가 실행되게끔 할려면 -d 옵션을 붙이면 된다


docker run -d --name "wildfly" -p 8080:8080 jboss/wildfly:latest 


6번에서 설명했을때는 -it옵션을 붙였으나 여기서는 background로 실행하는 것이기 때문에 컨테이너 표준입력을 사용할 수가 없다. 그걸 제외한 나머지 옵션은 동일하다

그러나 이렇게 실행하면 6번에서 컨테이너가 보여주는 로그들을 볼 수 없는 문제가 있다. 이를 볼려면 logs 명령어를 사용하면 된다


docker logs -f wildfly


-f 옵션은 linux 에서 tail 명령 사용했을때 -f 사용한 것을 생각하면 된다. 즉 로그를 계속 연속성으로 보여주는 것으로 이해하면 된다. 뒤에 wildfly가 붙은 것은 우리가 docker run을 이용해서 컨테이너를 실행할때 --name 옵션을 이용해서 주었던 그 wildfly이다. 이렇게 컨테이너를 run 명령어를 이용해서 실행할때 --name 옵션으로 별칭 준것을 docker 관련 명령 실행시 특정 컨테이너를 지칭하는데 사용함으로써 편리함을 준다.


9. 처음에 docker를 접하면서 난 docker의 이미지가 프로그램들의 모음(예를 들어 wildfly 컨테이너를 예로 들자면 wildfly와 이를 실행시키기 위해 필요한 부가적인 프로그램(예를 들면 jdk 같은)들의 모음)으로 이해했다. 그러나 docker 관련 구성도를 보면서 이해하게 된것은 컨테이너 안에는 os가 있다는 것이다. 즉 os 안에 관련 프로그램이 설치되어 있는 개념인 것이다. 이 부분은 나중에 build를 공부하면서 확연히 알게 되었다. 즉 기본 베이스 이미지를 centos 같은 리눅스 이미지로 삼은뒤 여기에 apache를 yum 명령어로 설치하면서 이미지 만드는 법을 알게 되었다 물론 베이스 이미지를 centos 같은 os 이미지가 아니라 wildfly 이미지를 사용할 수 있다. 그렇다해도 wildfly에 centos가 이미 있기 때문에 결국 wildfly 이미지에 있는 centos 를 이용하는 것임에는 변함이 없다. 이러한 개념이기 때문에 해당 컨테이너는 독자적인 OS와 그에 따른 환경변수를 가지고 실행할 수가 있는것이며 서로간의 컨테이너에 영향을 주지 않고 독립적으로 움직이게 되는 것이다.


docker 이미지는 os가 포함이 되어 있는 0개 이상의 프로그램이 설치되어 있는 이미지이다


10. 9번에서 설명했다시피 이미지는 자체적으로 OS가 포함되어 있다고 했다. 그렇기 때문에 우리는 컨테이너가 실행중일때 이 컨테이너를 구동시키는 기반이 되는 OS에 접속할 수가 있다. 즉 우리가 wildfly 이미지를 이용하여 컨테이너를 실행중일때 이 컨테이너의 OS에 연결할 수 있다는 것이다. 이것은 나름 작업(?)적인 차원에서 중요한 의미가 있다. 예를 들어 우리가 wildfly에서 구동중인 web application을 만든다고 가정해보자. 그러면 파일 업로드 기능을 넣어야 하는데 파일 업로드를 하게 되면 OS에서 관리되는 디렉토리 중 하나에 사용자가 업로드한 파일이 있어야 하며 그러한 디렉토리를 만들어놔야 한다. 그러면 이 디렉토리를 만들려면 wildfly 컨테이너의 os 쉘에 접근해서 디렉토리를 만드는 명령(mkdir)을 실행해야 한다. 이러한 OS 쪽의 작업을 하거나 또는 wildfly의 설정파일(예를 들면 standalone.xml)을 수정할 수 있다. 그리고 이렇게 변경이 된 내용이 있는 컨테이너를 docker commit 명령을 이용해서 새로운 이미지로 만들어 이를 다른 사람에게 배포할 수 있다.


서론이 길었는데 이 기능을 수행하는것에 대해 설명하도록 하겠다

먼저 경우를 분리해서 생각해야 할 부분이 있는데 우리가 컨테이너를 실행시킬때 /bin/bash 같은 쉘을 실행시킨 상황과 그렇지 않은 상황으로 분리해야한다. /bin/bash를 실행시켜서 현재 컨테이너가 bash shell이 실행중인 상황이면 docker의 attach 명령을 이용해서 접속하면 된다


docker attach wildfly


이러면 bash shell 에 접속하여 shell 명령어를 실행시킬수 있다. 여기서는 컨테이너 이름을 지칭하기 위해 wildfly를 썼지만 실제로 wildfly는 이렇게 명령해도 접속이 되질 않는다. 왜냐면 wildfly는 bash shell을 실행시키지 않고 컨테이너를 띄우기 때문이다. 때문에 attach 명령으로 접속 시도를 해도 동작이 되질 않는다. 또한 백그라운드로 실행시킨 컨테이너의 경우도 마찬가지이다(왜 그런지는 곰곰히 생각해보면 이해하기 쉽다. 우리가 background로 컨테이너를 실행시킨다는건 docker 명령어를 실제로 내리는 shell 창에서 억세스하는 것이 아니라 말그대로 background로 돌리는 것인데 거기서 shell 명령을 실행시키는 /bin/bash가 실행될리가 없잖은가?) 이렇게 /bin/bash 를 실행시키지 않고 시작한 컨테이너나 또는 background에서 실행중인 컨테이너를 접속하기 위해서는 exec 명령을 사용해서 /bin/bash를 실행시켜 접속하면 된다


docker exec -it -u root wildfly /bin/bash


이렇게 exec 명령을 통해 /bin/bash를 실행시켜서 bash shell 명령을 실행시킬수가 있게 된다. -u는 os의 어떤 계정을 통해서 명령을 실행시킬것인지를 지정하는 것이다. 그러면 어떤 계정을 사용해야 하는가? 그것은 해당 컨테이너의 docker 이미지를 build 하는데 사용된 Dockerfile의 소스를 보면 알 수 있다. 


일반적으로 docker 이미지들은 github 에서 이미지 관련 파일들이 존재하여 이를 github에서 빌드하여 docker hub에 배포되는 형태를 취하고 있다. 그래서 이 Dockerfile의 소스를 볼려면 github을 봐야한다. wildfly를 예로 들면 docker hub의 wildfly에 대한 페이지(https://hub.docker.com/r/jboss/wildfly/)를 가보면 Source 항목에 github과 링크되어 있는 링크를 볼 수 있다. 이를 클릭하면 github에 있는 해당 이미지를 빌드하는데 사용된 Dockerfile을 볼 수 있게 된다. 이 Dockerfile 을 클릭해서 상세 내용을 보면 USER 란 항목이 있어 Dockerfile을 이용해 빌드하면서 실행하게 되는 명령어를 수행하는 OS 계정을 언급하게 된다. 바로 이 USER 항목에 언급된 계정을 -u 옵션 뒤에 사용해주면 된다.  모든 docker 이미지가 root 계정을 사용하는 것은 아니기 때문에 이것을 확인하고 진행하기 바란다.


attach와 exec에 대한 추가 설명

위의 내용을 읽어보면 bash shell 기능을 위주로 설명했기때문에 현재 bash shell이 실행중인 컨테이너를 접속하여 할때는 attach, bash shell 이 실행중이지 않은 컨테이너를 접속하려 할때는 exec를 사용하는 것으로 이해가 될 것 같아서 부가설명을 하고자 한다.


attach는 현재 실행중인 컨테이너에 접속 한다고 보는 것이 맞다. docker 이미지가 컨테이너로 생성되면서 run이 될때 이미지 가 내부적으로 특정 프로그램을 실행시킬수도 있고 또는 run 명령을 내리는 시점에서 특정 프로그램을 실행 시키게도 할 수 있다. 이때 bash shell 이 실행되도록 /bin/bash 를 실행시켜서 attach 시 바로 bash shell prompt가 보이게끔 할 수도 있다. 그러나 그렇지 않은 이미지도 있다. 예를 들어 위에서 언급했던 wildfly 이미지의 경우 이 이미지는 컨테이너로 올라가는 시점에 wildfly의 standalone.sh 스크립트가 실행시켜 wildfly가 구동되도록 하고 있기 때문에 콘솔 화면에서 wildfly의 로그가 올라오는 것을 볼 수 있다. 그래서 docker의 attach 명령을 이용해서 wildfly의 컨테이너를 접속하면 wildfly 구동되고 있는 상황에서 나오는 콘솔로그를 볼 수 있다. 또한 이 상태에서 ctrl-c를 클릭하면 wildfly 가 실행되는 것이 종료되는 것을 볼 수 있다.


이에 반해 exec는 현재 실행중인 컨테이너에 특정 shell script를 실행하는 것이라고 보는게 맞다. 예를 들어 wildfly 이미지의 컨테이너가 wildfly란 이름으로 컨테이너가 실행되어 있는 상태에서 docker exec -it wildfly /bin/bash 로 명령을 내리면 해당 컨테이너에 bash shell을 실행시키는 것이다. 그래서 bash shell prompt가 화면에 나오게 되는 것이다. 만약 /bin/bash가 아는 사용자가 만든 별도 스크립트를 실행시키면 그 스크립트가 실행시키는 것이다(exec 명령어를 사용할때 -it 옵션을 주었기 때문에 해당 명령의 실행 결과가 현재 보는 화면에 바로 보이게 된다)


11. docker 에서 등록되어 있는 컨테이너 목록을 확인 하는 명령은 다음과 같이 한다


docker ps -a 


-a 옵션을 빼고 docker ps 로 실행하게 되면 현재 동작중인 컨테이너만 보여주기 때문에 중지되어 있는 컨테이너는 보여주지 않게 된다. 그래서 -a 옵션을 항상 붙여서 중지되어 있는 것도 같이 확인하는 버릇(?)을 들이는 것이 좋다


12.  docker에서 실행중인 각 컨테이너가 사용하는 CPU 및 메모리 점유율 등 컨테이너의 상태를 확인하기 위해서는 다음의 명령을 사용한다


docker stats


13. 중지되어 있는 컨테이너를 구동하는 명령은 다음과 같이 한다


docker start wildfly


14. 실행중인 컨테이너를 중지시키는 명령은 다음과 같이 한다.


docker stop wildfly


15. 컨테이너를 재시작할때의 명령은 다음과 같이 한다


docker restart wildfly


16. 컨테이너를 삭제할때의 명령은 다음과 같이 한다


docker rm -f wildfly


원래 컨테이너를 삭제할때는 현재 상태가 중지되어 있는 컨테이너만 삭제가 가능하기 때문에 실행중인 컨테이너는 삭제를 할 수가 없다. 그러나 -f 옵션을 붙이면 실행중인 컨테이너도 삭제하게 된다

현재 컨테이너에 등록되어 있는 모든 컨테이너를 삭제하고자 할 때는 다음과 같이 한다


docker rm $(docker ps -a -q)


여기에 위에서 설명한 -f 옵션을 붙이면 실행중인 컨테이너까지 모두 삭제하게 된다


17. 현재 구동중인 컨테이너에서 실행 중인 프로세스를 모두 일시정지 시키고자 할 때는 다음과 같이 한다


docker pause wildfly


일시정지된 컨테이너를 docker ps 명령어를 이용해서 컨테이너 목록으로 확인해보면 Status에 Paused로 나온다(참고로 stop 명령을 이용해서 컨테이너를 중지시킨 경우 docker ps 명령을 이용해 목록을 확인해보면 Status에 Exited로 나온다)

이렇게 일시정지된 컨테이너를 다시 재시작 시킬때는 다음과 같이 한다


docker unpause wildfly


18. 현재 구동중인 컨테이너에서 실행중인 프로세스를 확인할때는 다음과 같이 한다


docker top wildfly


linux에서 top 명령을 실행한것과 같은 유형의 결과물을 보여준다


19. 구동중인 컨테이너에서 실행중인 프로세스가 이용중인 포트를 확인하고자 할때는 다음과 같이 한다


docker port wildfly


이렇게 하면 우리가 위에서 실행한 wildfly의 경우 다음과 같이 나타날 것이다


8080/tcp ->0.0.0.0:8080


이것은 컨테이너의 8080 포트(왼쪽의 8080/tcp)를 호스트 컴퓨터(정확하게는 현재 내가 사용중인 OS)의 8080 포트(오른쪽의 0:.0.0.0:8080)와 연결되고 있음을 의미한다.


20. 컨테이너와 호스트 컴퓨터 간의 파일 복사는 다음과 같이 한다


docker cp wildfly:/opt/jboss/wildfly/standalone/configuration/standalone.xml D:/dockerimages


위의 명령은 wildfly 컨테이너의 /opt/jboss/wildfly/standalone/configuration 디렉토리에 있는 standalone.xml 파일을 호스트 컴퓨터의 D:/dockerimages  디렉토리에 복사한다는 뜻이다. 

명령어의 구조가 docker cp 복사대상파일 복사되는위치 구조이기 때문에 이 구조만 맞춰주면 마찬가지로 호스트에서 컨테이너로 파일 복사를 할 수 있다. 위에서 언급한 명령을 호스트에서 컨테이너로 복사하는 개념으로 바꿔서 한다면 다음과 같이 한다


docker cp D:/dockerimages/standalone.xml wildfly:/opt/jboss/wildfly/standalone/configuration


이렇게 하면 호스트 컴퓨터의 D:/dockerimages/standalone.xml 파일을 wildfly 컨테이너의 /opt/jboss/wildfly/standalone/configuration 디렉토리에 복사하게 된다. 명령어를 유심히 보면 알겠지만 컨테이너의 디렉토리나 디렉토리에 있는 파일을 언급할때는 컨테이너 이름과 컨테이너의 디렉토리 또는 파일 사이에 :(콜론)을 붙인다(wildfly:/opt/jboss/wildfly/standalone/configuration/standalone.xml)


21. 기본적으로 Docker에서 실행되는 명령은 OS의 root 계정으로 실행이 된다(그도 그럴것이 Dockerfile에서 ENV를 이용해서 OS의 환경변수도 설정이 가능하기 때문에 이런것이 가능할려면 root 계정일수 밖에 없다) 그러나 root 계정이 아닌 다른 계정을 만들어서 명령을 실행시켜야 할 수도 있다. 이럴땐 Dockerfile에서 해당 계정을 만든뒤 USER 명령을 이용해서 해당 계정으로 바꾼다. 그러면 그 후에 실행되는 것은 해당 계정으로 실행하는 것이 된다. 


22. 현재 실행중인 컨테이너를 이미지로 만들어야 할 수 있다. 이미지로 제공되는 설정을 컨테이너로 실행되게 한 상태에서 해당 설정을 바꾸고 이를 이미지로 저장해서 재사용할 수도 있기 때문이다. 이럴때는 commit 명령을 이용한다. 예를 들어 wildfly란 이름의 컨테이너를 terry/wildfly 란 이미지로 저장하고자 할 때에는 docker commit -a "Terry Chang" wildfly terrychang/wildfly 로 명령을 실행한다. 이때 a 옵션은 이미지를 제작한 제작자를 설정하는 옵션이다.


23. 이미지를 특정 파일로 백업하고 특정 파일을 이미지로 복구할때 save/load 명령을 사용할 수 있다. 이와 비슷한 것으로 export/import 가 있다. 이 둘의 차이는 save/load는 그 대상이 이미지인것에 반해 export/import는 그 대상이 컨테이너(엄밀하게 말하면 export 명령을 이용해서 컨테이너를 특정 파일로 백업한뒤에 import를 이용해서 그 특정 파일을 이미지로 복구하는 것이다. 이 부분 헷갈리지 말도록)이다.

예를 들어 terrychang/wildfly란 이미지를 D:/dockerimages/customwildfly.tar 파일로 백업할때는 다음과 같이 한다.


docker save -o D:/dockerimages/customwildfly.tar terrychang/wildfly


이와는 반대로 D:/dockerimages/customwildfly.tar 파일을 terrychang/wildfly란 이미지로 복구할때는 다음과 같이 한다


docker load -i d:\dockerimages\customwildfly.tar


24. docker 이미지를 빌드할때는 빌드할때 필요한 파일들만 들어가 있는 디렉토리에 Dockerfile을 넣고 빌드해야 한다. 이게 나름 중요한데 Docker는 이미지를 빌드 할때 빌드명령이 실행된 디렉토리에 있는 모든 파일을 특정 공간에 업로드하고 사용한다. 이 과정을 몰라서 Dockerfile 파일을 가상 리눅스 머신 파일이 있는 곳에 넣고 빌드를 하다보니 빌드랄 할때 가상 리눅스 머신 파일이 같이 올라가면서 이 올라가는 과정만 계속 하다가 결국 뻗어버리는 증상이 있었다. 그래서 빌드를 할때는 Dockerfile 파일과 Dockerfile 안에서 빌드할때 사용되는 파일 및 디렉토리만 있게 하고 빌드 명령을 실행시켜야 한다.


25. centos나 ubuntu docker 이미지 파일의 경우 경량화(?)를 하는 이유로 백그라운드 서비스를 관리하는 systemd가 빠져있다. 그래서 centos의 경우는 centos에서 배포하는 centos/systemd 이미지를 사용하면 systemd를 이용한 백그라운드 서비스 관리를 이용할 수 있다. 이때 /usr/sbin/init 을 실행해야 한다. 이 init이 pid가 1이어야 systemd를 이용할 수 있다. 문제는 init을 실행하면서 별도 shell script(a.sh 라고 가정하자)를 실행해야 하는 상황이 있을수가 있는데 그럴때는 별도 shell script 파일(b.sh 라고 가정하자)을 만들고 이 파일에서 /usr/sbin/init과 a.sh가 실행이 되도록 하면 된다. 이때 주의할 점이 있는데 반드시 /usr/sbin/init 이 가장 마지막에 실행되도록 shell script를 만들어야 한다. 나는 pid가 1이어야 한다고 생각해서 /usr/sbin/init을 가장 먼저 실행되게끔 했는데 이렇게 하니까 b.sh가 실행이 되지 않는 문제가 발생하였다.  다음은 wildfly의 standalone.sh와 /usr/sbin/init이 실행되게끔 한 shell script 파일 소스이다.


#!/bin/bash

# background로 wildfly를 실행시킨다. 
# 원래는 /opt/jboss/wildfly/standalone/log/server.log 파일에 로그를 기록하지만 
# 별도 로그파일을 만들어서 보고 싶을 경우엔 
# /dev/null 부분을 특정 로그(ex: /usr/log/wildfly.log)로 지정하면 그 파일에 로그를 기록하게 된다

nohup /opt/jboss/wildfly/bin/standalone.sh -b 0.0.0.0 -bmanagement 0.0.0.0 > /dev/null &
exec /usr/sbin/init


26. 25번의 연장선상에 해당되는 설명인데 /usr/sbin/init을 실행할 경우 Dockerfile의 ENV를 이용해 설정한 환경변수가 이미지에 적용이 되지 않는다. 원래 ENV를 이용해서 환경변수를 설정하면 이것이 빌드할때 이미지에 반영되어 이 이미지를 컨테이너로 실행시킬때 해당 환경변수가 OS에 적용이 되는데 /usr/sbin/init이 실행되면 이 기능이 되지를 않는다(리눅스를 몰라서 구체적으로 설명하기는 어렵지만 구글링을 해보면 이 증상은 당연한 것이라고 나온다) 그래서 이와 같이 /usr/sbin/init이 실행되는 이미지가 컨테이너로 실행이 되는 상황에서 환경변수가 인식이 되게끔 할려면 /etc/environment 파일에 해당 환경변수가 기록이 되게끔 Dockerfile에 서술해주면 된다. 예를 들어 다음의 코드를 Dockerfile 안에 넣어주면..


RUN echo -e "LANG=ko_KR.utf8\nLC_ALL=\nJAVA_HOME=/opt/java" > /etc/environment


/etc/environment 파일이 다음과 같이 된다. 


LANG=ko_KR.utf8
LC_ALL=
JAVA_HOME=/opt/java


그러나 위의 내용은 Dockerfile을 통해 빌드를 해서 이미지를 만든뒤 컨테이너로 올려 실행할때의 발생되는 문제이지 Dockerfile에서 ENV로 설정한 환경변수를 빌드하는 과정에서 해당 환경변수를 이용할때는 문제가 없다. 예를 들어 ENV JAVA_HOME=/opt/java 로 했다고 가정할 경우 Dockerfile에서 이 환경변수를 이용하기 위해 RUN mv jdk* ${JAVA_HOME} 로 했을 경우 JAVA_HOME은 /opt/java로 인식되어 mv 명령을 수행하게 된다. 즉 빌드하는 과정에서 ENV로 설정한 환경변수를이용하는데는 문제가 없으니 오해없길 바란다.  


27. 25,26번의 연장선상에 해당되는 내용인데 26번에서 /usr/sbin/init을 실행하면 ENV로 설정한 환경변수가 이미지에 적용이 안되어 컨테이너에서 이 환경변수를 이용할 수 없다고 했다. 이런 문제때문에 환경변수를 이용해 지정하게 되는 PATH 또한 이 영향을 받게 된다. 이 부분을 해결할려면 /etc/profile.d 디렉토리에 별도의 shell script 파일이 생성되게끔 해서 컨테이너가 시작될때 이 shell script가 자동으로 실행이 되도록 한다. 예를 들어 Dockerfile에 ENV JAVA_HOME=/opt/java 을 넣고 다음의 코드를 Dockerfile에 넣어주면

 

RUN echo -e "export PATH=$PATH:$JAVA_HOME/bin" > /etc/profile.d/path.sh


빌드하는 시점에 $JAVA_HOME은 /opt/java로 인식이 되어 /etc/profile.d/path.sh 파일엔 export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/java/bin 가 들어가게 된다.


28. github에서 빌드 관련 파일들을 올려두고 Docker Hub와 연동해서 이미지 빌드 작업을 진행 할 경우 간혹 이런 메시지를 볼 수 있다


/assets/setup.sh: /bin/bash: bad interpreter: Text file busy


로칼에서 빌드할때는 이런 에러가 없었는데 Docker Hub로 연동해서 빌드할때 이런 에러 메시지가 나온다. 구글링을 한 바로는 이럴때 해당 shell 스크립트 파일을 실행하기 전에 sync 명령어를 실행하라고 해서 이 에러메시지를 잡았다. 

위의 에러 메시지가 나타나게 된 Dockerfile 코드를 예를 들어 구체적으로 설명하자면 에러 메시지가 나올당시의 Dockerfile 코드는 다음과 같이 되어 있었다


RUN chmod +x /assets/setup.sh && /assets/setup.sh


위의 코드를 다음과 같이 에러 메시지를 유발시키는 shell script(여기서는 /assets/setup.sh) 파일 앞에 sync를 추가로 넣어 실행이 되게끔 했다.


RUN chmod +x /assets/setup.sh && sync && /assets/setup.sh


이렇게 코드를 수정한뒤 빌드해서 에러 없이 빌드를 마쳤다


29. docker 컨테이너를 올리는 과정에서 다음의 에러 메시지를 docker logs 명령을 통해 확인되는 경우가 있다


standard_init_linux.go:195: exec user process caused “no such file or directory”


이 에러가 발생하는 상황이 딱히 정해져 있지는 않아서 지금 말하는 이 상황에서만 발생한다고 말할수는 없어보이나 나의 경우는 지금 말하는 이 상황에서만 발생하여서 이에 대해 정리를 하고자 한다.


docker 이미지를 만드는 과정에서 이런 저런 이유로 shell 파일들을 안에 넣게 되는데, 이때 shell 파일의 개행문자 처리 방식이 Windows일 경우 이 증상이 나타난다. 그래서 이럴땐 shell 파일의 개행문자 처리 방식을 Unix로 바꿔주면 된다.


Notepad++의 경우엔 shell 파일을 연뒤에 notepad++ 맨 밑에 우측을 보면 Windows (CR LF) 라고 나오는 부분이 있다. 이것은 개행문자를 Windows 형태 즉 \r\n의 초합으로 한다는것을 의미한다. 이 Windows (CR LF) 라고 나오는 부분을 마우스 우클릭하면 조그만 팝업 메뉴가 나타나는데 여기서 Unix 형식으로 변환 을 선택하면 개행문자 처리 방식을 Unix 형태 즉 \n 형태로 바꾸게 된다.


30. network와 관련하여 별도의 설정을 하지 않으면 docker container는 외부 인터넷 망에 대한 연결은 가능한 상태이지만 정작 docker를 운영하는 host와는 연결이 되지 않는 상태가 된다. 그래서 host와의 연결을 하기 위해 bridge 네트워크를 생성해야 할 필요성이 있다. 이럴때 다음과 같이 bridge network 를 생성한 뒤에 이를 이용하면 된다


docker network create -d bridge --subnet 192.168.100.0/24 --gateway 192.168.100.1 dockernet


docker network --help 하면 괸련 명령어의 설명을 볼 수 있는데 create는 생성할때 사용하는 명령이다 -d로 네트워크를 관리할 드라이버를 지정해야 하는데 여기엔 bridge와 overlay 이렇게 2개가 있다. 만약 container가 해당 container를 운영하는 host 및 그 host가 운영하는 container들 하고만 통신한다면 bridge 로 설정하면 된다. 그러나 이 container가 자신을 운영하는 host 뿐만 아니라 기타 다른 docker host 및 이 host가 운영하는 container들과 통신해야 한다면 이때는 overlay 로 설정한다(-d를 지정하지 않으면 default로 bridge로 설정된다) --subnet 과 --gateway는 이 생성된 network가 이용하게 될 ip 영역대와 gateway를 지정하게 된다. 위의 예시를 들어 설명한다면 192.168..100.2~255 번까지의 ip 주소들을 생성하고자 하는 network를 사용할 container가 자신의 ip 주소로 사용하게 되고, 이에 대한 gateway는 192.168.10.1을 사용하게 된다. 마지막으로 dockernet은 생성하게 되는 network의 이름을 지정하는 것이다. 이렇게 하면 docker network ls 명령을 이용해서 현재 생성된 network 들의 목록을 보게 될 때 dockernet 이란 이름으로 현재 생성한 network가 보이게 된다.


이렇게 network를 생성하게 되면 이제 이렇게 생성된 network를 docker container가 이용해서 사용하도록 해주어야 한다. 이것은 docker run을 이용해서 container를 실행시킬때 --net=dockernet 을 주어 docker container가 dockernet 네트워크를 이용하게끔 해주면 된다. 또 docker-compose 에서 이를 이용할땐 다음과 같은 방법으로 사용해주면 된다.


version: '2.1'


services:

  terrycentos:

    image: furywolf/centosprod

    container_name: centosprod

    cap_add:

      - SYS_ADMIN

    volumes:

      - /sys/fs/cgroup:/sys/fs/cgroup:ro

      - d:/docker/volumes/centos:/mnt/shared:rw

    ports:

      - "21:21"

      - "2122:22"

      - "64000-64010:64000-64010"

    networks:

      dockernet:

        ipv4_address: 192.168.100.200

networks:

  dockernet:

    external: true


services:terrycentos:와 같이 서비스명을 지정한 상태에서 하위에 networks란 멤버를 둔뒤에 여기에 사용하고자 하는 network인 dockernet을 지정한다. 그리고 networks:dockernet: 을 통해 해당 dockernet network를 지목한 상태에서 external: true를 줌으로써 docker host로의 접속이 허용이 되게끔 한다. docker run의 경우 host로의 접속이 허용되게 하는것은 기본 설정인데 만약 이를 막고자 할경우(host 접속하는 것을 막고자 하는 경우) --internal 옵션을 docker run 명령의 옵션으로 주면 된다


31. 30번의 경우는 container가 host로 접속을 하는 것에 해당하지만 host가 container가 가지고 있는 ip로의 접속이 된다는 뜻은 아니다. 그래서 이것을 하기 위해서는 이제부터 설명하게 될 설정을 해야 할 필요가 있다. 이 방법을 하면 30번에서 설명했던 container에서 host로의 연결도 같이 해결되기 때문에 30번에서 설명한 설정을 할 필요가 없다.

docker for windows 의 경우 container에 할당되는 ip는 192.168.100.X 형태의 내부 ip로 받게 되어 있다. 그러나 Windows 10에서 Network 관련 설정을 보면 docker와 관련된 ip 설정은 10.0.75.X 형태의 ip 설정만 존재하고 있다. 즉 192.168.100.X와 10.0.75.X와의 연결고리가 존재하지 않는 것이다. 그래서 이를 해결하기 위해 Windows 10 명령 프롬프트 창(CMD로 실행되는 명령 프롬프트창)을 관리자 권한으로 실행시킨 뒤 다음의 명령을 입력한다


route -p add 192.168.100.0 MASK 255.255.255.0 10.0.75.2


이렇게 입력하면 서로 다른 두 ip 영역대에 대한 연결관계가 성립이 되어 host와 container간의 ip로의 통신을 할 수 있게 된다(host에서는 container의 ip를 통한 통신이, container에서는 host의 ip를 통한 통신이 가능해진다)


위의 내용은 docker for windows에서 해당하는 내용이지 docker for mac이나 linux에서 운영중인 docker 에서도 사용가능한 방법인지는 확인되지는 않았다.


참고한 내용은 여기에서 했다(질문자인 whitecolor가 남긴 세번째 답변 글에서 참조했다)


중요 : 이걸 확인하려고 할때 ping을 이용해서 확인하면 안된다. docker conatainer 에서 host인 windows 로 통신여부를 체크할때는 ping을 써도 상관없지만 host인 windows에서 docker container로 통신여부를 체크할때는 ping을 사용하면 안된다. windows에서 port ping을 체크할 수 있는 프로그램인 tcping 을 다운받아서 특정 포트가 열려있는 컨테이너에서 포트에 대한 통신으로 체크하면 된다(ex : tcping 172.100.0.2 8080)


이것을 설정할 경우 개인적으로 가장 큰 장점이라 꼽히는 것은 container ip에 container port를 직접적으로 접근할 수 있다는 것이다. 예를 들어 우리가 container의 port를 이용하고자 할때 docker run 명령에서 -p 옵션을 사용하게 된다. -p 3080:8080 이렇게 주면 host의 3080 포트를 container의 8080 포트와 연결하는 것이다. 그래서 host ip:3080 하면 container의 8080 포트와 연결을 하게 되는 것이다. 그러나 container ip를 직접 접근할 수 있게 되면 container ip:8080 하는 식으로 host를 거치지 않고 container의 포트를 직접 접근할 수 있게 된다


※ 주의사항


처음 30번에서 설명한 route 설정을 할때 IP를 다음과 같이 설정했었다.


route -p add 172.0.0.0 MASK 255.0.0.0 10.0.75.2


이렇게 설정하니까 얼마 안있어 구글을 이용해서 검색을 하는데 문제가 생겼다. 계속 timeout이 걸렸는데..

이게 어떤때는 검색이 될 때도 있었고 되지 않는 때도 있어서 애를 좀 먹었다.

나중에 원인을 파악해보니 구글(www.google.co.kr) 도메인 주소가 DNS 서버를 통해 IP로 번역이 될때 172.217.160.67 이었는데..

route로 172로 시작하는 모든 IP 주소를 10.0.75.2로 연결하게끔하다보니..

구글 도메인 주소가 10.0.75.2를 통해 연결되는 상황이 벌어졌다.

이로 인해 검색이 되지 않는 문제가 생겼다.(검색이 되었을때의 IP 주소는 172로 시작하는 IP 주소가 아니었다)

그래서 docker container에 ip를 부여할때는 잘 알려지지 않고 사용하지 않는 IP 주소로 최소한의 범위로 route를 해주는게 좋다.

위에서와 같이 172.0.0.0 이런식으로 172로 시작하는 모든 주소 이런식으로 하지 말고..


route -p add 192.168.100.0 MASK 255.255.255.0 10.0.75.2


192.168.100 으로 시작하는 주소만 연결되게끔 하고 (MASK 설정도 IP 구성하는 4개 중 앞의 3개에 255를 설정하여 3개는 항상 고정이 되게끔 해준다)..

docker container가 사용할 네트워크도 위에서 설명한 것과 같이 192.168.100.0/24 이런 식으로 앞의 3개는 항상 고정되게끔 해주면 이런 상황을 피할수가 있다.

기존에 잘 되는 도메인 주소가 제대로 동작하지 않을때 해당 도메인 주소의 ip를 알아낸 뒤 이 ip가 docker 관련쪽으로 route 되는지 확인해보자


32. docker-compose.yml 파일에서 volume 항목을 다음과 같이 설정해야 할 때가 있다


/sys/fs/cgroup:/sys/fs/cgroup:ro


이것을 설정하는 이유는 systemctl 같은 서비스 기동/종료 명령을 사용하기 위해 설정하게 되는데 docker for windows 가 버전업이 되면서 docker-compose 명령 사용시 이 설정 부분에 에러가 발생하는 경우가 있다

이때는 windows 환경 변수의 시스템 변수에 COMPOSE_CONVERT_WINDOWS_PATHS 항목을 만들어 여기에 1을 설정해주면 해결된다


33. 최근에 docker 를 docker for windows 가 아닌 vagrant 기반으로 바꾸면서 이슈가 발생한 것이 있다. docker for windows 를 설치할 경우 docker 가 실행되는 곳은 localhost 이지만 vagrant 기반으로 할 경우 docker 는 vagrant의 linux vm에서 실행이 되기 때문에 docker 이미지를 빌드하는 경우 이를 vagrant의 linux vm에 1차적으로 들어가야 하기 때문이다. 즉 docker host가 localhost가 아닌 vagrant vm이 되어버렸기 때문에 docker 관련 명령을 실행할 경우 localhost가 아닌 vagrant vm 하에서 실행한 결과가 나와야 하기 때문이다. 이를 위해서 다음과 같은 절차를 거쳤다(이 설명대로 할 경우 vagrant 설치 및 vm 생성, 그리고 거기에서의 docker 설치는 이미 되어 있어야 하기 때문에 여기서는 그것과 관련된 내용은 말하지 않겠다)


- 나는 centos 기반의 vagrant vm에 docker를 설치했는데 docker를 설치한 후 systemctl 기반에서 제어되도록 하기 위해 다음의 과정을 미리 거쳐놨다


sudo systemctl enable docker


- 위의 과정을 거치면 /usr/lib/systemd/system 경로에 docker.service 파일이 생기게 되는데 이 경로로 이동한뒤 이를 vi 에디터로 연다. 이때 sudo 명령어를 이용해서 연다


sudo vi docker.service


- vi 에디터로 열면 [Service] 항목에 다음과 같은 내용이 있다(이 내용과 일치되지 않을수는 있겠으나 ExecStart 부분을 보면 된다)


ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock


여기서 -H fd:// 부분을 다음과 같이 수정한다


ExecStart=/usr/bin/dockerd -H tcp://0.0.0.0:2375 --containerd=/run/containerd/containerd.sock


이렇게 하면 docker daemon을 2375번 포트를 통해 접속할 수 있게 해주기 때문에 외부에서도 docker daemon이 접속 가능하게 되어 docker client가 해당 서버의 docker daemon에 접속하여 명령을 내릴 수 있게 된다.


docker.service 파일을 저장한 뒤 다음의 명령들을 실행한다


sudo systemctl daemon-reload

sudo systemctl restart docker


이렇게 한 뒤 netstat -tnlp 를 실행하면 해당 vagrant vm에 열려있는 port 중 다음과 같이 위에서 설정한 2375 번 포트가 열려있는 것을 발견할 수 있다


tcp6       0      0 :::2375                 :::*                    LISTEN      -


(IntelliJ에서 docker 접속시 다음과 같은 설정을 통해 접속이 되는 것을 확인했다)



위의 그림에서 192.168.100.2 는 vagrant에서 실행되고 있는 docker가 설치된 centos vm의 ip 이다. 이렇게 설정하면 192.168.100.2 에서 실행중인 docker daemon에 접속하여 접속된 daemon에서 docker 관련 명령을 실행할 수 있다.


34. 33번의 과정을 거치고 난 뒤에 발생한 또 하나의 문제는 vagrant의 linux vm에서 docker 명령이 실행되지 않는 문제가 발생되었다. 이를 해결하기 위해 다음의 명령어로 환경변수를 설정했다


export DOCKER_HOST=tcp://0.0.0.0:2375


35. 31번 글과 비슷한 내용의 글인데 vagrant 를 알게 된 뒤로는 docker 환경을 vagrant centos 에 docker를 설치한 뒤 이를 활용하는 식으로 접근하고 있다. 31번과 같이 windows에서 vagrant 안에서 실행중인 docker container와 직접적인 통신을 하기 위해 route 문을 사용했지만 route 명령에 대한 문외한으로 인해 늘 실패했었는데 이제 성공하게 되어서 글을 남긴다.

docker container가 가지고 있는 ip가 10.10.20.15이고 vagrant 가상머신(docker가 설치되어 있는 가상머신)의 ip가 192.168.100.2 라고 가정할 경우 route add 명령을 다음과 같이 작성해주면 된다


route -p add 10.10.20.0 MASK 255.255.255.0 192.168.100.2


이렇게 하면 192.168.100.2의 IP를 가지고 실행중인 docker가 설치된 vagrant 가상머신에서 10.10.20.X 대의 IP를 가지고 실행중인 docker container와 windows 간의 통신이 가능할 수 있게 된다. 








'프로그래밍 > Docker' 카테고리의 다른 글

Hyper-V에 CoreOS 설치하기(2)  (0) 2017.11.12
Hyper-V에 CoreOS 설치하기(1)  (0) 2017.11.12
docker에 대한 형식없는 정리  (0) 2017.07.19

트랙백을 확인할 수 있습니다

URL을 배껴둬서 트랙백을 보낼 수 있습니다

다른 카테고리의 글 목록

프로그래밍/Docker 카테고리의 포스트 목록을 보여줍니다

MSI GL62 7RD-I7 사용기

2017.03.07 13:11

지난 글에서는 MSI GL62 7RD-I7 노트북의 개봉기를 작성했다. 이번엔 이 노트북에 대한 사용기 위주로 적어볼까 한다. 참고로 나는 직업이 프로그래머라 프로그래머 관점에서 사용기를 작성하고자 한다. 그렇다고 일반 사용자에 대한 내용이 아주 없지는 않다. 다나와에 작성한 사용기에서는 일반 사용자에 대한 내용도 적었기 때문에 여기서도 이 내용을 다시 언급하도록 하겠다.


먼저 이 노트북에서 제공하는 3가지 유틸에 대해 설명을 좀 하겠다.  이 노트북에는 다음의 3가지 유틸을 제공한다


  • SCM
  • Dragon Center
  • Nahimic


먼저 SCM은 Windows의 제어판을 들어가지 않아도 무선랜(Wifi), 블루투스, 웹캠, 디스플레이를 키거나 끄고 볼륨과 화면 밝기를 제어해주는 프로그램이다.



Dragon Center는 노트북을 모니터링하고 노트북의 전원 옵션과 쿨링 옵션등 노트북 성능과 관련된 부분에 대한 제어를 해주는 프로그램이다. 이 Dragon Center는 노트북 전원 버튼의 왼쪽 옆에 있는 버튼을 눌러도 바로 실행이 되는 프로그램이다. 




그림을 보면 알겠지만 CPU, 메모리, GPU, 디스크 사용율과 CPU, GPU의 온도, 그리고 이 둘을 식혀주는 역할을 하고 있는 쿨링팬의 속도등을 모니터링해주고 있다(이 노트북엔 쿨링팬이 2개가 있다) 게이밍 노트북의 특성상 이런 프로그램은 사용자에게 충분히 어필이 되는 지점이다.  두번째 그림인 시스템 튜너를 통해서 노트북이 제공하는 특정 기능을 켜거나 끌 수 있으며 쿨링 팬 속도, 다음에 설명할 Nahimic에 대한 설정, 모니터 RGB 색상에 대한 설정 등이 가능하다. Dragon Center를 언급하면서 쿨링팬이 잠깐 언급되었는데 전원버튼의 왼쪽에 있는 쿨링팬 버튼을 누르면 2개의 팬이 모두 최고속도로 돌게 된다.


Nahimic은 노트북의 사운드, 마이크를 컨트롤하여 게이밍 등 자신이 사용하는 환경에서 보다 몰입되는 환경을 제공해주는 프로그램이다. 음원 칩셋 회사마다 제공하는 음장 효과 설정에 마이크 제어 기능이 추가로 있는 그런 프로그램이라 보면 된다.



유틸에 대한 설명은 이 정도로 마치고 그럼 실제 내가 사용하는 프로그램 위주로의 사용기를 쓰도록 하겠다. 직업이 프로그래머(정확하게는 자바 웹개발자)이다보니 게임보다는 프로그래밍과 관련된 개발툴을 주로 사용하며, 주로 쓰는 개발툴은 이클립스이다. 이전 글에서 이 노트북을 사용하기 전에 사용했던 노트북을 보여준적이 있지만 그 노트북은 4기가 램에 500기가 5400rpm 하드디스크여서 정말 이클립스 하나 띄우는데 세월아 네월아 해야만 했다(참고로 나는 이클립스를 2.1 버전때부터 써왔는데 그때는 정말 빠릿빠릿하게 실행되는 놈이었다. 그러나 얘도 시대의 흐름을 무시할수는 없어서 이런저런 것들에 대한 개발이 가능하게끔 하다보니 어느덧 점점 무거운 프로그램이 되어버렸다..ㅠㅠ) 근데 이 노트북으로 이클립스를 설치한 뒤 실행하면서 정말 놀라운 경험..속된말로 신세경..을 경험하게 되었다. 사람들이 왜 SSD SSD 노래를 부르는지를 알게 된 것도 있지만 전반적으로 개발환경이 많이 쾌적해졌다. 그도 그럴것이 이번에 노트북을 사면서 M2 SSD에 32기가로 메모리를 업그레이드 했기 때문에 메모리에 대한 부담감을 확실히 많이 줄일수가 있었다. 자바 개발자들이 계속 고민하는 이클립스 설정의 메모리 고민을 거의 안하다시피 할 수준까지 되어버렸다. 일단 M2 SSD에 32기가 메모리라는 것을 염두해두고 밑의 영상을 보길 바란다. 밑의 영상에서 사용된 이클립스는 이클립스 4.6.2 Neon에 Spring 개발을 위한 플러그인과 JBoss 연동을 위한 플러그인만 설치된 상태에서 처음 띄우는 속도를 보여주는 것이다(폰카로 찍은 동영상이기 때문에 화질에 대한 기대는 하지 말아주시길..)



작업표시줄에 있는 아이콘 클릭부터 시작해서 우리가 접할 수 있는 코딩화면을 볼 수 있을때까지 약 12초 정도 걸렸다. 영상에서 실행시킨 이클립스의 JVM 옵션 중 메모리 설정부분만 따로 언급하면 다음과 같다


-vmargs

-Dfile.encoding=UTF-8

-Xverify:none

-XX:+UseParallelGC

-XX:-UseConcMarkSweepGC

-XX:PermSize=64M

-XX:MaxPermSize=512M

-XX:MaxNewSize=512M

-XX:NewSize=128M

-Dosgi.requiredJavaVersion=1.8

-Xms1024m

-Xmx1024m


전체 메모리가 32기가이다 보니 Xms와 Xmx 옵션을 1기가로 주어도 상관이 없을 정도다. 다음 영상은 이렇게 띄운 이클립스에서 Tomcat에 연동된 Web 프로젝트를 띄울때의 영상이다. 이때 사용된 Web 프로젝트는 현재 개인 공부 및 강좌 목적으로 개발한 Spring Data JPA와 Spring Security를 사용하는 개인 소규모 프로젝트이다. 이걸로 퍼포먼스를 논하는 것은 말도 안되지만(그럴용도로 이 영상을 찍은 것도 아니다) 자신이 이 노트북을 이용하여 개발할 때 과연 이 노트북으로 답답함이 없는 개발환경하에서 운영될 수 있는지를 가늠하는 하나의 방법으로써 봐주길 바란다



동영상에서 로그가 잘 안보이겠지만 7초 정도면 Tomcat의 Server start up 메시지를 볼 수 있다. 


다음으로는 안드로이드 스튜디오 2.3의 로딩 영상이다. 개인적으로 안드로이드 개발자는 아니지만(공부만 띄엄띄엄 한 정도로..) 안드로이드가 7.0 누가가 나온 시점에서 한번 재정리 하는 차원의 공부를 해보고픈 욕심에 설치해보았다. 안드로이드 개발자가 이 노트북을 자신의 구매목록의 후보군으로 올려놓았다면 한번 눈여겨볼 부분일수도 있지 싶어 찍어봤다. 영상에서 사용된 프로젝트는 안드로이드 스튜디오가 기본적으로 만들어주는 내용으로만 구성된 프로젝트(Empty Activity 하나만 존재하는..)이다.



예전에 안드로이드 공부했을땐 이클립스로 했었는데 이번 공부부터는 안드로이드 스튜디오로 바꿔서 해볼려고 설치를 했다. 일단 메모리를 업글하다보니 AVD Manager를 이용해서 가상 디바이스를 만들때 가상 디바이스가 사용하게 되는 메모리를 충분히 줄 수 있어서 가상 디바이스를 좀더 효율적으로 사용할 수 있었다. 그러나 안드로이드 스튜디오를 초반에 만지작거리면서 이용하다보니 갑자기 노트북 팬이 돌기 시작하면서 소음이 발생하였는데 Dragon Center를 통해 확인해보니 CPU 온도가 50도를 넘어가는 상황이 벌어졌었다. 좀더 AVD Manager를 통해서 가상 디바이스를 외부 그래픽 장치를 사용해서 표현하게끔도 설정했지만 이 팬 돌아가는 상황은 피할수가 없었다. 그래서 도서관 같이 조용한데서 이걸 이용하는 것은 약간 눈치가 보인 점도 있었다(실제 이 상황이 벌어졌을때가 도서관의 노트북실에서 이용할때의 상황이어서 조금 난감했었다)


지금까지 프로그래머 위주의 사용기를 작성했고 이제 일반인들 위주의 사용기를 쓰도록 하겠다. 지금부터 쓰는 내용은 다나와에서 내가 작성한 사용기와 동일하다시피한 내용이기 때문에 다나와에서 본 사람들은 이 부분을 패스하고 마지막 부분으로 넘어가도 된다(마지막 부분은 다나와 사용기에서 언급하지 않은 내용들이기 때문에..) 이 노트북 자체가 게이밍 노트북이고 일반인이든 프로그래머든 이 노트북을 구매대상의 후보군으로 올렸을때는 게이밍에 대한 성능도 하나의 구매 포인트가 될 수 있기 때문에 이 부분을 언급하지 않을 수 없다. 개인적으로는 이 노트북을 작업용 노트북으로 사용할 것이어서 게임은 설치하지 않는 편이지만 이 게이밍 벤치마크 테스트 때문에 2개의 게임을 설치했다. 스타크래프트 2와 스나이퍼 엘리트 3를 가지고 게이밍 성능에 대한 내용을 진행하려 한다. 두 게임 모두 최상위 옵션으로 설정한 상태에서 진행했다


스타크래프트는 워낙 국민게임이라 별도의 설명은 할 필요가 없고 이것의 속편인 스타크래프트 2는 비록 전작만큼의 인기는 얻지 못하고 있으나 각종 게임 대회가 열리고 있을 정도로 많이 알려져는 있는 게임이다. 전체적인 프레임은 게임 화면이든 컷씬이든 동영상이든 60 프레임 이상은 보여주어서 끊어짐을 전혀 느낄수는 없었다. 다만 화면이 약간 어둡게 표현되는것 같아 옵션에서 Gamma 수치를 조금 올려서 조금 밝게 설정한 부분은 있었다. 프레임은 스타크래프트 2가 제공하는 명령어를 이용해서 체크했으며 화면 좌측 상단에 보면 프레임 수치를 보여주고 있다. 다만 이것이 너무 작게 나오고 있어서 그림 아래에 이 수치를 별도로 명시해줬다


63 FPS


74 FPS


88 FPS


다음으로 언급할 게임은 스나이퍼 엘리트 3 이다. 요즘들어 개인적으로 빠져 있는 게임인데 제 2차 세계대전을 배경으로 스나이퍼가 되어 독일군을 죽이는 그런 스토리의 게임이다(이 게임은 다른 의미로 더 잘 알려져 있는 게임인데 궁금한 사람은 YouTube에서 이 게임 관련 영상을 검색해보면 알 수 있다) 일반적인 FPS 게임같이 혼자서 막 종횡무진으로 뛰어다니며 총을 쏘는 그런 류의 게임이 아닌 잠입 액션 형식이 더 강하기 때문에 프레임 테스트 용도로 적합하지 않을 수는 있겠으나 이 게임 안에 벤치마크용 프로그램이 있어서 이걸로 테스트 해 보았다. 프레임 체크도 역시 스타크래프트 2와 같이 게임에서 자체적으로 제공되는 명령어를 이용했으며 그림을 보면 좌측 상단에 프레임 수치를 보여주고 있지만 이것 또한 그림에서는 작게 보여서 그림 밑에다가 이 수치를 같이 적어놓도록 하겠다


게임에서 제공되는 벤치마크 테스트 결과

 

 70 FPS


83 FPS


이제 글을 마무리 하는 단계에서 이 노트북에 대한 장점과 단점을 정리하도록 하겠다. 장점으로는 뛰어난 가성비이다. I7 7700HQ CPU를 사용하고 8 기가 메모리에 1 TB 하드디스크를 장착한 노트북 치고는 가격이 100만원 언저리(정확하게는 99만원)이었다. 이것도 그래픽 카드를 조금 낮춘걸로 잡으면 90만원 이하의 가격에서도 살 수가 있다(현재 소개하는 이 모델은 Geforce 1060을 사용하고 있다. 이것은 M 모델이 아니다) 게이밍 노트북으로써 아쉬운 점이 있다면 키보드에 백라이트 기능이 제공되지 않는 것인데 이 기능이 본인에게 중요시된다면 이 기능이 지원되는 모델도 판매하고 있기 때문에 그걸로 선택하면 된다(그러나 이 모델은 100만원이 넘는다) 그러나 나는 이 노트북을 게이밍을 생각하고 구매한 것이 아니기 때문에 이 옵션이 중요하진 않았다. 그리고 이 노트북은 확장성도 좋은 편이다. 메모리 뱅크가 2개가 있으며 최대 32기가까지 가능하고 기존의 하드 디스크 적재공관과는 별개로 M2 SSD와 멀티 부스트를 지원하고 있기 때문에 저장장치를 M2 SSD, 2.5 인치 하드 디스크 2개를 설치 할 수 있다. 또 CPU와 GPU에 쿨러가 각각 설치되어 있어서 노트북의 온도 관리로는 최적의 솔루션이지 싶다. 더군다나 CPU, GPU 쿨러를 시스템에 맡기지 않고 자신이 직접 제어할수도 있다.


일단 장점은 이쯤하고 이제 한 보름 정도 쓰면서 느낀 단점을 적도록 하겠다. 지금부터 말하는 단점들은 절대적인 단점이 아니다. 즉 글쓴이인 나에게는 단점일 수 있으나 다른 사람에게는 단점이 아닐수도 있다. 어디까지나 개인이 사용하는 환경에 맞춰서 장점과 단점이 부각되는 것이기 때문에 지금부터 말하는 단점을 액면 그대로 받아들이지 말고 자신의 사용 환경과 맞추어서 생각해보길 바란다. 자신과는 상관없는 부분이면 단점이 아니기 때문이다.  먼저 자판 배열이 기존의 익숙한 배열과는 다른 점이 단점이다. 윈도우 키가 일반적으로는 스페이스바를 기준으로 왼쪽에 있지만 이 노트북의 키보드에는 오른쪽에 있어서 윈도우 키를 자주 사용하는 입장에서는 익숙하지 않은 부분이 있다. 또 스페이스바와 한/영 변환 키 사이에 \(|)가 있다. 개인적으로는 \를 자주 사용한다. 프로그래머하면 \를 자주 사용하는 편이다보니 스페이스바 옆에 있으면 이것은 나름 장점일수 있겠지만 프로그래머가 아니라면 한영키가 있는 위치에 \가 있기 때문에 오타의 소지가 다분하다. 이점 때문에 스페이스바 옆에 있는 \키가 나에게는 장점이자 단점이 되고 있다. 그리고 Home과 End 키를 쓸려면 FN 키를 눌러야 하는 점이 단점이었다. 개인적으로 프로그래밍 코딩을 하다 보면 Home과 End가 PGUP과 PGDN 보다 그 사용빈도가 더 높은편인데..PGUP과 PGDN은 바로 사용할 수 있지만 Home과 End는 FN 키를 눌러야 하다보니 번거롭다. 물론 일반인들은 오히려 PGUP과 PGDN이 훨씬 사용빈도가 높기땜에 이 부분은 단점으로는 부각되지는 않을것이다. 또 쿨러 소리로 인한 소음이 단점이다. 사실 쿨러란 것은 양날의 검이다. 노트북의 온도를 제어하는데는 사실 쿨러만한게 없지만 쿨러는 소음을 동반하기 때문에 고속의 쿨러 동작은 당연 노트북의 소음을 유발한다. 그리고 이런 소음은 특히 조용한 곳일수록 더더욱 부각이 된다. 요즘 플젝이 끝나서 공부하느라 도서관을 다니는데 도서관에서는 안드로이드 스튜디오를 실행시킬수가 없다. 그걸 실행하면 온도가 올라가서 쿨러가 동작하기땜에..물론 쿨러 동작을 사용자가 제어할 수 있기 때문에 속도를 늦출수는 있겠지만 번거로움을 피할수는 없다. 


지금까지 프로그래머로서 이 노트북에 대한 평가를 해봤다. 개발하는 용도로는 가성비는 뛰어나다고 생각한다. 얇은 노트북은 휴대성은 좋지만 저전력 CPU를 사용하기 때문에 개발에 적합하지 않은 측면이 있고 그렇기땜에 어쩔수 없이 휴대성은 포기할수 밖에 없지만 이 노트북은 그렇게 무겁다는 느낌도 없고 성능도 좋으며 확장성도 좋고 더구나 가격적인 측면에서도 아주 만족스럽다. 개발자들 사이에어야 맥북을 쓰고 싶어하지만(나도 맥북 쓰고 싶긴 하다) 가격때문에 접근할수가 없다. 결국 가성비 뛰어난 노트북을 찾게 되는 것이고 그점에 있어서 이 노트북은 합격점인 그런 노트북이다.








 

트랙백을 확인할 수 있습니다

URL을 배껴둬서 트랙백을 보낼 수 있습니다

다른 카테고리의 글 목록

사는 얘기/나의 흔적 카테고리의 포스트 목록을 보여줍니다

MSI GL62 7RD-I7 개봉기

2017.03.07 13:11

이 블로그 내용은 MSI 노트북 이벤트와 관련되어 다나와에 작성되어 있는 최고의 가성비 노트북 MSI GL62 7RD-I7 개봉기 및 사용기 의 업그레이드 버전 글임을 밝혀둔다. 당연 다나와에 작성되어 있는 글도 본인이 이벤트의 일환으로 작성한 글이다. 그래서 다나와 사용기에서 보여주는 사진의 일부가 이 글에서도 같이 보여질수 있다. 오해없길 바란다.



내 블로그를 방문하는 사람은 알겠지만 나는 직업이 프로그래머이다. 그러다보니 항상 노트북을 끼고 살 수 밖에 없는 처지여서 노트북은 늘 나에겐 친구 이상의 그런 존재이다(노트북에 생명이 있다면 얘가 기분이 좋으면 내 능률도 오르고 기분이 나쁘면 능률이 떨어지는 것은 당연..) 그러다보니 노트북으로 개발을 하는 나에겐 노트북의 성능은 무멋보다 중요한 요인이다. 그걸 깨닫게 하는게 요즘 참여하고 있는 프로젝트였는데..



위의 사진은 내가 현재 참여하고 있는 프로젝트에서 사용중인 노트북이다(바탕화면은 걍 서비스루다가 감상하시길..) 삼성 노트북인데 3세대 I5인가..암튼 그런 CPU에 램 4기가, 결정적으로 5400 RPM의 하드 디스크를 장착한 노트북을 사용하고 있는 중이다. 보안을 요구하는 곳이라 각종 보안 소프트웨어가 설치된 상태에서 전원을 키고 부팅을 시도하면 정말 완료될때까지 세월아 네월아 하며 기다려야 하는 상황이었다. 그뿐이랴..각종 서버 프로그램을 띄워야 할 때면 그거 뜨는 동안에도 손가락을 빨아야 했다..과거 이 노트북을 샀을 당시만 해도 쓰는데 큰 문제는 없었지만 노트북을 구입한지 5년이 되어간 시점에서는 이 노트북을 샀을때 같이 샀던 이제는 너덜너덜해진 노트북 가방과 마찬가지로 이 노트북 또한 점점 생명이 다해갔다. 진행하던 프로젝트가 약 보름정도 남은 상황에서 슬슬 노트북을 알아봤고 그래서 사게 된 것이 지금부터 소개하게 되는 MSI GL62 7RD-I7 게이밍 노트북이 되겠다


이 노트북의 사양은 밑의 그림과 같이 되겠다



요약하자면 인텔 카비레이크 I7 7700HQ, DDR4 RAM 8기가, 지포스 GTX 1050, 1 테라 바이트 하드디스크로 구성된 노트북이다. 나는 이 기본 사양에서 업그레이드를 좀 더 해서 RAM 32기가로 구성하고 512 M2 SSD를 추가로 장착했다. 늘 그렇듯이 내가 내 돈 내고 구입한 제품의 사용기이기 때문에 온라인 구입 내역을 올려둔다(참고로 가격과 판매처는 일부러 모자이크 처리를 했다. 왜냐면 가격과 판매처를 보여주면 홍보로 보일 오해의 소지가 있어서..)




배송 및 포장 상태는 정말 최상의 상태로 왔는데 최종 노트북 박스를 내 눈으로 볼때까지 난 3개의 박스를 먼저 열어야 했다. 



이렇게 배송된 박스를 개봉하면



이렇게 뽁뽁이를 5번정도 두른 박스를 만나게 되며 뽁뽁이를 풀른뒤의 박스를 열면


이렇게 박스와 부가적인 주문품들(노트북 살 당시에 키스킨과 노트북 액정 보호필름을 같이 주문했으며 이벤트 기간에 주문한거라 MSI 게이밍 마우스를 선물로 받았다)과 박스를 보게 되고 이제 여기서 다시 박스를 또 열어야..


이렇게 노트북이 들어있는 최종 박스를 볼 수 있었다. 정말 이런 포장상태면 노트북이 정말 천재지변을 만나지 않는 한에야 배송중에 파손이 될래야 될 수 없었을 것이란 생각이 들었다. 물론 이것은 MSI 본사가 아닌 판매처의 정성이지만..


박스를 보면 MSI 게이밍 노트북의 트레이드 마크인 붉은 용 그림이 그려져 있다(간혹 MSI 노트북 관련 구매 이벤트를 보면 이 트레이드 마크인 용(용용이로 불린다) 인형을 주는 경우가 있다) 이제 이 박스를 열면..



이렇게 노트북 보호용 봉투(적당한 단어가 떠오르질 않아서..)로 씌워진 노트북을 딱딱한 스펀지가 좌우로 감싼 상태의 포장상태를 볼 수 있다. 박스 안의 왼쪽 종이 박스 안에는 어탭터와 전원 케이블이 들어있고 노트북 밑에는 종이 매뉴얼과 드라이버가 들어있는 CD가 있다(사실 이 제품은 DVD 드라이브가 없고 그 자리를 멀티부스트로 만들어 여기에 1테라 하드를 설정한 상태로 출시되기 때문에 이 드라이버 CD는 사실상 사용이 불가능하다. MSI 홈페이지에서 드라이버를 다운로드 받을 수 있다)

이런 포장상태에서 노트북과 어댑터를 꺼내면 다음과 같은 노트북의 모습을 볼 수가 있다.



노트북 상판에도 역시 MSI 게이밍 노트북의 트레이드 마크인 붉은 용 그림의 엠블렘을 볼 수 있다. 어댑터의 크기를 가늠하기 쉽게 하려고 노트북 위에다가 어댑터를 놓고 사진을 찍었다. 어댑터의 길이가 노트북 가로 길이의 약 절반에 해당하는 길이로 길이는 큰 편이지만 두께는 노트북 두께보다는 얇은 편이라 어댑터는 무겁다는 느낌이 들지는 않았다. 무게만 놓고 보면 오히려 기존에 쓰던 삼성 노트북보다도 가볍게 느껴졌다.



위의 사진은 OS를 설치한뒤 다나와에서 이 노트북 사용기를 작성하던 시점에 찍은 사진이다. 폰카로 찍다보니 노트북 모니터 화면이 이상하게 나왔지만 노트북 패널에 문제가 있는 것이 아님읋 밝혀둔다. 펼쳐져 있는 상태에서 노트북 두께를 봐도 그리 두꺼운 편은 아니다(두께도 이전의 삼성 노트북이 더 두꺼웠다. 하긴 그 사이의 세월의 흐름이란 것이 있으니 그 사이에 기술 또한 발전했을테니까..) 사진을 보면 키보드라 하향게 빝나서 마치 백라이트 기능이 있는것 같지만 이 노트북은 백라이트 기능이 없다.




폰카로 근접해서 찍다보니 화질이 양호하지 않음을 감안하고 보길 바란다. 키보드는 풀키보드형식의 키패드까지 모두 포함되어 있는 구조이며 자판과 자판 사이가 간격이 벌어져 있어서 오타도 줄일수 있다.(위에 올린 두 장의 키보드 사진중 아래쪽 사진을 유심히 봐두길 바란다. 다음 글에서 언급할 이 노트북의 단점에 대해 언급할때 아래의 사진과 연관이 있다)


이것으로 MSI GL62 7RD-I7 개봉기를 마치도록 하겠다. 다음 글에서는 이 노트북을 본격적으로 사용하는 사용기에 대해 언급하도록 하겠다. 다나와 사용기를 작성했던 시점에서 1주일정도 지나 이 글을 쓰다보니 이 노트북의 단점도 좀 발견한 부분이 있었는데 이 부분에 대해서도 마저 언급하도록 하겠다.



트랙백을 확인할 수 있습니다

URL을 배껴둬서 트랙백을 보낼 수 있습니다

다른 카테고리의 글 목록

사는 얘기/나의 흔적 카테고리의 포스트 목록을 보여줍니다

기존에 쓰던 마우스는 다이소에서 판매하는 5000원짜리 마우스였다. 정말 싼맛에 샀는데..역시 싼맛의 마우스는 한계가 있었다. 한 6개월 정도 사용하니 마우스 휠을 돌리면 정상적인 동작을 하지 않았다. 그래서 이번엔 평소에 쓰고 싶었던 마음만 간직하고 있었던 버티컬 마우스를 사용하고자 알아보게 되었다. 그러나 일반적인 버티컬 마우스들이 한 2만원대여서 기존 마우스보다 약간 가격이 높은 관계로 고민을 하게 되었다. 처음 써보는 버티컬 마우스인데 나에게 맞는지 안맞는지 불확실한 상태에서 가격이 쎈걸 질르면 돈낭비겠다 싶어서 가격이 싼 버티컬 마우스를 알아보다가 주변기기 전문업체인 Cosy에서 1만원도 안되는 가격에 내놓은 버티컬 마우스가 있어서 질르게 되었다(물론 택배비를 포함하면 1만원이 넘어가지만..) 내가 직접 사용할 목적으로 구매한 제품이기에 회사로부터 그 어떠한 협찬도 받지 않았으며 여기 11번가에서 구매한 구매내역을 올리도록 하겠다



상품의 포장상태 및 배송은 나쁘지 않았다. 주문을 저녁에 한 관계로 주문을 한 날로부터 이틀뒤에 도착했다. 아래 사진은 박스 포장을 열은뒤의 사진과 박스에서 꺼낸 뒤의 사진이다.




이 사진을 보면 박스 안에 들어있는 제품의 상태를 보고 포장이 부실하다고 느낄수 있는데 이 제품의 케이스가 투명한 플리스틱 박스(적당한 표현이 생각이 안나서 투명한 플라스틱..이라고 했지만 우리가 일반적으로 사용하는 핸드폰 액정 보호필름의 재질을 생각하면 된다. 대신 그거보다는 훨씬 두껍다)로 되어 있기 때문에 정말 어지간한 큰 충격이 발생해서 극단적으로 외부박스가 찌그러지는 일이 있지 않는한에는 파손이 되지 않는다. 제품 박스의 옆면과 뒷면에는 각각 잡은 모습과 제품에 대한 설명이 있다 




버티컬 마우스를 컴퓨터에 장착하면 다음과 같은 모습이 된다.



사진을 보면 파란색 곡선으로 된 줄이 보일텐데 마우스가 USB에서 전원을 공급받아 저 부분에 파란색 불빛이 나오게 된다. 아래의 사진은 마우스를 손으로 잡은 모습이다.



남자손 치고는 작은 손이어서 마우스가 한 손에 들어오지는 않기 때문에 여자분들에게는 이 마우스가 비교적 큰 크기일수도 있다. 그리고 기존의 마우스와는 달리 잡는 자세가 바뀌었기 때문에 손이 편하다는 느낌을 받았다(이 마우스의 클릭을 하는 느낌을 글로 표현하자면 권총을 잡고 방아쇠를 당기는 느낌..이라고 생각하면 된다) 마우스를 위에서 손으로 감싸며 손가락을 눌러 클릭을 하는 것과는 보다 손에 익숙한 느낌을 준다. 사진을 보면 버튼이 3개가 있는데 엄지 손가락 위에 있는 버튼 2개는 웹브라우저 앞, 뒤로 이동하는 버튼이고 DPI 라고 쓰여진 버튼은 마우스 DPI 를 조정하는 버튼이다. 지금보니 실질적으로 마우스 클릭 버튼이 있는 반대편은 찍지를 못했다(팔을 반대로 돌려서 셀카를 찍는것은 무리여서..ㅠㅠ..)


이 제품의 장점은 역시 저렴한 가격에 있다. 시중에 나와있는 버티컬 마우스의 제품군이 많이 있지도 않다보니 이 제품을 제외한 나머지 제품들은 2만원이 넘었다(에누리 사이트에서 비교한 결과였다) 버티컬 마우스의 특성이 기존 마우스보다 손목을 편하게 해주다보니 이런 장점을 살리면서 보다 저렴한 가격으로 구매할 수 있다는 것은 큰 장점이다. 그러나 이에 못지 않은 단점도 있는데..


일단 첫번째 단점은 마우스의 높이가 기존의 마우스보다 높다보니 나 같이 키보드와 마우스를 놓는 서랍 형태의 컴퓨터 책상에서는 서랍을 밀어넣을 수 없는 단점이 있다. 위의 사진을 보면 알 수 있는데 마우스의 높이가 서랍의 여유공간 높이보다 더 크기 때문에 서랍을 밀어넣을수가 없다. 이건 전혀 생각치고 못했던 부분이어서 당혹스러웠지만 키보드와 마우스를 책상 위에 놓고 쓰는 사람의 경우엔 이러한 단점은 발생하지 않기 때문에 문제가 되진 않을것이다. 나 같이 서랍식으로 키보드와 마우스를 놓는 사람에게는 고려해야 할 포인트가 된다.


두번째로는 제품 자체의 단점으로 낮은 DPI 이다. 위에서 잠깐 버튼을 설명할때 DPI 버튼을 설명했는데 이 제품이 제공하는 DPI는 1000, 1600 이렇게 2개만 지원한다. 기존에 사용하던 다이소 마우스가 이거보다 높은 2400 DPI를 지원하다보니 1600 DPI를 써도 마우스를 움직일때 딥딥함이 좀 있다. 개인적으로 스나이퍼 엘리트3 게임을 즐겨 하는 편인데 조준하는데 있어 답답한 느낌?..물론 이거보다 비싼 마우스도 1600 DPI가 최대이긴 했지만 개중엔 3200 DPI까정 지원해주는 버티컬 마우스도 있었다. 물론 가격은 이거보단 3배정도 비쌌다


마지막으로 기존 마우스보다 약간 무거운 느낌이 있다. 확실히 잡는 형태가 바뀌기 때문에 손목의 피로는 덜지만 기존 마우스보다는 큰 관계로 그만큼 무게가 나간다. 물론 무게가 나가기 때문에 마우스를 움직일때 안정적인 느낌을 주는 것은 있지만 미세하다고는 해도 그만큼 힘을 더 들여야 하기땜에 거기에서 오는 피로가 좀 있다.


평소에 버티컬 마우스가 어떤지 궁금한 사람에게는 저렴한 가격으로 판매하는 이 마우스를 먼저 사서 자신에게 맞는지 확인하고 좀더 나은 제품으로 구매했으면 한다. 자신에게 맞는지 안맞는지도 모르고 비싼 가격의 마우스를 먼저 살 필요는 없기 때문이다.

트랙백을 확인할 수 있습니다

URL을 배껴둬서 트랙백을 보낼 수 있습니다

다른 카테고리의 글 목록

사는 얘기/나의 흔적 카테고리의 포스트 목록을 보여줍니다

요즘같이 USB 포트를 통해 충전하는 전자기기들이 우리 주위에 많이 존재하게 되는 상황에서 USB 포트 충전기 또한 보조밧데리 못지않게 무척이나 중요하게 되었다. 그러다보니 시중에 이런저런 USB 멀티포트 충전기들이 많이 있게 되었다. 대기업조차 자신들의 이름을 내걸고 이 시장에 뛰어들고 있는 상황이다. 그러나 이 USB 멀티포트 제품들이 처음 나올때부터 안정적인 제품이 나온것은 아니었다. 근데 내 기억에 유일하게 안정성이 있는 제품으로 각인된 것이 있었는데 그것이 바이퍼럭스의 제품이었다. 


그러나 그 당시 나는 이 제품을 살 필요성을 느끼지 못했다. 그 당시에 내가 가지고 있는 USB 포트를 이용해서 충전하는 전자기기는 스마트폰이 유일했기 때문에 스마트폰을 사면 같이 주는 충전기 하나로 충분했기 때문이었다. 그러나 내 주변의 전자기기가 태블릿과 블루투스 헤드셋이 생기면서 스마트폰 충전기 하나로 이 3가지를 돌려가며 충전하는 것은 개인적으로 무척 짜증이 나는 상황이 되었다. 또한 그 사이에 스마트폰을 G4로 바꾸게 되면서 급속충전 기능이 있게 됐지만 내가 가지고 있는 충전기는 이러한 요건을 만족하지 못했다. 


이런 상황에서 과거의 기억을 떠올려 바이퍼럭스 제품을 찾게 되었고 바이퍼럭스에서 퀵차지 기능을 지원하는 충전기 제품들을 내놓게 되면서 제품을 구매하게 되었다. 이 글은 이런 이유로 구매하게된 바이퍼럭스 클레버 60W 6포트 타키온 충전기의 개봉기 및 사용기가 되겠다. 이 제품을 사기 전에 다른 사람들의 사용기를 봤다. 그들은 USB 전력 측정을 이용한 값들을 보여주었지만 나는 그런 장비도 없고 그냥 전문적인 블로거 입장이 아닌 일반 소비자 입장에서 이 글을 쓰고자 한다. 그래서 구체적인 전력수치를 알고 싶은 사람이라면 다른 사용기를 읽어보길 바란다. 개인적인 용도로 산 것에 대한 사용기이므로 그 어떤 협찬도 받지 않았으며 이를 증명하기 위해 11번가의 내 구매내역을 올리도록 하겠다(11번가에서 진행하는 쇼킹딜을 통해 구매했다)



위에서 보면 알수 있지만 주문할때 충전기와 타키온 급속충전 5핀 케이블 1미터짜리 3개도 같이 구매했다. 그러나 제품에 대한 인상은 처음 시작부터 좋지는 않았다. 우선 위의 주문일자를 보면 알겠지만 12월 19일날 밤에 주문한 제품이 20일날 오전 9시에 배송되었다고 문자가 왔지만 정작 내 손에 제품이 쥐어진 날짜는 12월 22일이었다. 즉 배송이 하루 지연되었다. 이 충전기를 구매할 당시 다른 제품들도 산 것들이 있었는데 그것들은 21일날 도착했지만 이 제품은 하루 늦게 도착했다. 그 덕분에 11번가에서 배송지연보상 포인트를 받긴 했지만 배송이 늦은걸로 이 제품에 대한 인상을 갖는걸 시작했다. 그 담부터는 포장상태였다. 아래 사진은 내가 아무것도 건드리지 않고 배송 박스만 열어놓은 사진이다.



그 흔한 완충제도 없이 달랑 충전기 제품 박스와 케이블 박스 이렇게 2개가 들어있는 상태로왔다. 택배 특성상 배송될때 박스에 특별히 명기되지 않는 한에는 거칠게 다뤄지는 것을 생각하면 이런 포장은 정말 어이없었다. 그러나 이것은 바이퍼럭스의 문제가 아니었다. 첨에 난 이 제품을 바이퍼럭스가 운영하는 매장에서 산것으로 알았는데 매장은 바이퍼럭스의 제품을 취급할뿐 바이퍼럭스가 운영하는 것은 아니었다(바이퍼럭스가 운영하는 매장은 바이퍼럭스 회사 주소와 동일했는데 이 매장은 주소가 틀렸다) 혹시나 오해하는 사람이 있을까봐 밝혀두는 바이다. 그러나 이렇게 배송을 다루는 매장도 있다는 것을 알아두었음 하는 생각에서 글을 썼다. 


이제 아래와 같이 배송박스에서 본격적으로 제품을 꺼내서 살펴보도록 하겠다.



우선 타키온 60W 6포트 타키온 충전기(이하 타키온 이라 하겠다) 박스를 열어보도록 하겠다. 박스는 제품이 들어있는 속 박스를 제품 그림이 그려져 있는 겉 포장지가 둘러싸여 있는 형태이다. 아래의 사진은 이런 겉 포장지와 속 박스를 분리해낸 모습이다.



이제 타키온이 들어 있는 속 박스를 열어보면 아래와 같이 타키온이 들어있다. 나는 검은색을 선택해서 검은색 제품이 왔다. 박스에 보면 타키온에 대한 바이퍼럭스의 자신감이 느껴지는 문구가 있음을 볼 수 있다.



이제 검은색 타키온을 꺼내면 아래와 같이 제품 설명서가 보이게 되며



이 설명서를 꺼내면 아래와 같이 전원케이블 및 타키온 받침대가 들어있다. 이 받침대를 이용하면 타키온을 세워서 놓을 수 있다.



가로, 세로, 높이의 수치로 제품의 크기를 알려줄수 있지만 수치만 봐서는 잘 와닿지 않을수 있을 것 같아 개인적으로 가지고 있는 물건중 비교 대상이 될만한 물건과 같이 놓아 사진을 찍었다. 아래 사진은 내 방에 있는 iptime 유무선 공유기와 타키온을 같이 놓은 후 위에서 찍은 사진이다. 이 사진을 보면 타키온이 어느 정도의 가로와 세로 크기를 가지는지 알 수 있으리라 생각된다.(개인적으로 담배를 피지 않지만 담배갑이 있다면 담배갑보다는 조금 더 큰 크기이다)



아래 사진은 타키온와 공유기를 앞에서 찍은 사진이다. 높이는 공유기 높이와 비슷하다



다음으로 볼 것은 같이 주문한 급속 충전 케이블이다. 충전 케이블은 아래와 같이 3개가 한 박스에 들어있다.



아래 사진은 가운데 케이블만 꺼내어서 찍었다. 케이블 자체에 대한 포장은 아래 사진과 같이 묶여서 포장되어 있다.


지금까지는 배송 및 포장 상태를 살펴보았고 이제 본격적으로 제품 설치 및 퀵차지 기능에 대해 얘기해보고자 한다. 제품 설치야 머 단순하다. 전원 케이블과 충전케이블을 타키온에 연결하고 충전 케이블에 전자기기에 연결하면 끝!!!



책상위에 마땅히 놓을만한 곳이 없어서 일단 이렇게 셋팅해보았다. 위의 사진에서 보다시피 타키온에 물려있는 전자기기는 소니 블루투스 헤드셋, LG G Pad 8.0, LG G4 이렇게 3개이다. 타키온은 6개의 USB 포트를 제공하는데 이 중 2개는 퀄컴의 퀵차지 2.0이 지원되는 고속충전기능을 제공한다. LG G4와 G Pad는 고속충전 포트에 연결했고 블루투스 헤드셋은 일반 포트에 연결했다. 일반 포트에 연결해도 부족함이 없는것이 포트당 최대 2.4A 출력을 내주기 때문에 기존 1A보다는 훨씬 낫다. 


다음은 고속충전기능에 대해 써보도록 하겠다. 삼성 갤럭시 스마트폰 사용자들이 워낙 많다보니 인터넷 검색을 좀만 해보면 퀵차지 기능을 사용할때 갤럭시가 어떤 모습을 보여주는지의 이미지를 손쉽게 볼 수 있다. 그러나 LG 폰에 대해서는 잘 나타나지를 않아서 이 참에 이 부분에 대해 캡춰해서 보여주고자 한다. 타키온의 고속 충전 포트가 아닌 일반 충전 포트에 연결하면 아래와 같은 잠금화면을 보여준다. 단순히 충전중...이란 문구와 그 옆에 현재 충전율을 보여주는 형식이다.



이러한 상태에서 잠금을 풀고 스마트폰 위의 상태바를 드래그해서 보면 아무런 것도 나타내는 것이 없다.


그러나 고속 충전 포트를 G4에 연결하면 잠금화면에서 약간 다른 모습을 보여주게 되는데, 고속 충전 중...이란 문구를 보여줌으로써 퀵차지 기술을 이용한 충전중임을 알 수 있다(제품설명에 보면 G4는 퀄컴 퀵차지 2.0을 지원하는 것으로 나오고 있다)


또한 잠금화면을 풀고 상단 상태바를 드래그해보면 아래 사진과 같이 고속 충전 중이라고 하면서 빠르게 충전 중이라는 안내 문구도 보여주는 것을 알 수 있다.



이렇게 고속 충전 기능이 있는 전자기기를 일반 충전 포트와 고속 충전 포트에 연결했을때 각기 다른 모습을 보여주기 때문에 전자기기가 고속 충전중인지 아닌지를 확연히 알 수 있다. 그러나 G Pad는 고속 충전 기능을 지원하지 않기 때문에 이러한 모습을 볼 수 업었다.(블루투스 헤드셋이야 말할 필요가 없고..) 그러나 위에서 언급했다시피 일반 충전 포트를 이용해도 최대 2.4A의 출력을 통한 충전이기 때문에 기존 충전보다 빠른 것을 느낄 수 있었다.


이 글을 쓰는 시점이 크리스마스인 12월 24일인데 마침 퇴근해서 스마트폰 충전 상황을 보니 19%뿐이 안남아서 이 시점에서 타키온 고속 충천 포트에 연결한 상태에서 얼마만에 완충이 되는지 체크해보았다. 완충 되었을때 폰에서 별도 알람이 울리지 않아서 정확한 시점을 알 수는 없었지만 1시간 정도만 충전하면 100%까지 되는 것을 확인할 수 있었다.



타키온을 내게 팔은 매장의 배송 및 포장상태만 빼면 타키온 제품은 개인적으로 상당한 만족도를 보여주었다. 위에서도 얘기했다시피 USB 충천 케이블 하나로 3개의 전자기기를 돌려가며 충전하는 그런 번거로움이 없어진것도 정말 나로서는 너무 좋았다. 크기도 작아서 공간을 그리 잡아먹지 않는 이점도 있다. 그러나 개인적으로 약간 아쉬운 점이 2가지가 있었다. 이것은 전적으로 내가 처한 상황 때문에 생긴 단점이기 때문에 모두에세 적용되는 것은 아님을 먼저 밝혀둔다. 


하나는 짧은 전원 케이블이다. 내 경우는 책상 뒤로 선을 돌려서 선정리를 깨끗하게 하고 싶었는데 선이 짧아서(전원선은 약 1 미터 정도 되는 길이다) 선을 돌려서 할 수 없었다. 그래서 어쩔수 없이 책상 앞쪽으로 전원선을 내려서 멀티탭에 꽃아둔 상태다. 물론 다이소 같은데서 전원 연장선을 사서 해결 할 수 있겠으나 애초에 좀더 길게 뽑아주면 면 그런 연장선 없이 해결이 될 수 있는 것임을 생각하면 아쉬움이 없지 않아 있다.


다음으로 충전 상태를 알 수 있는 표시 방법이다. 충전을 시작하게 되면 USB 포트 옆에 조그만 파란 불빛이 나오는 것을 볼 수 있다. 불빛의 색상을 달리 주어서 일반 충전중인지, 고속 충전중인지를 알 수 있게 해주면 전자기기를 일부러 들여다보지 않아도 알 수 있을텐데 그 점이 약간 아쉬웠으며 이 불빛의 위치 또한 포트 옆에 조그맣게 있기 때문에 잘 보이지 않는 것도 있다. 차라리 바이퍼럭스 로고가 있는 제품 옆면에 LED를 2개 달아서 일반 충전시엔 파란색, 고속 충전시엔 오렌지색이 들어오게 해서 일반 충전, 고속 충전 동시에 진행중이면 LED 2개가 동시에 불이 들어오는 그런 형식으로 해주었다면 훨씬 알아보기 좋을텐데..하는 생각이 들었다. 


그러나 이러한 개인적인 단점을 크게 웃도는 제품의 성능으로 인한 장점이 있기 때문에 제품의 구매 가치는 충분히 있다. 현재 내 차량용 충전기도 조금 상태가 안좋아서 제품을 알아보고 있는데 이 바이퍼럭스 타키온 제품을 접하고서 바이퍼럭스 차량용 충전기도 살까..하는 생각을 갖고 있다. 오늘 12월 24일 기준으로 쇼킹딜에서 8일의 기한이 남아 있으니 관심 있는 사람은 쇼킹딜에서 조금 할인된 가격으로 구매하길 바란다. 충분히 제값을 하는 제품이다.

트랙백을 확인할 수 있습니다

URL을 배껴둬서 트랙백을 보낼 수 있습니다

다른 카테고리의 글 목록

사는 얘기/나의 흔적 카테고리의 포스트 목록을 보여줍니다