$ sudo apt-get update
$ sudo apt-get install docker.io
$ sudo ln -sf /usr/bin/docker.io /usr/local/bin/docker

우분투에서 docker를 설치할 때, docker.io로 설치해야함

'서버' 카테고리의 다른 글

[Linux] scp 명령어  (0) 2016.10.06
[docker] jenkins 설치  (0) 2016.09.24
[docker]우분투 docker 설치  (0) 2016.09.24
서버 다중화 (Active-Active, Active-Standby)  (0) 2016.08.25
x86 서버, 블레이드 서버, 랙 마운트 서버  (0) 2016.06.25
젠킨스란?  (0) 2016.06.20

서비스의 가동률을 높이는데에 여러가지 방법 중 서버 다중화를 설명하겠습니다.

다중화 구성에는 다중화된 요소를 모두 이용할 수 있는 Active-Active와 다중화된 요소 중 한쪽은 사용할 수 없는 Active-Standby 두 종류가 있습니다. Active-Standby는 Standby의 방식에 따라 다시 세 종류로 나뉩니다.

Hot StandbyStandby 측은 가동 후 즉시 이용가능한 구성
Warm StandbyStandby 측은 가동 후 이용가능하게 하기 위해서 나름대로의 준비가 필요한 구성
Cold StandbyStandby 측을 정지시켜 두는 구성

Active-Standby 다중화 구성의 예


기술적으로 가능하면 Active-Active가 가장 가동률이 높아집니다. 데이터를 저장하지 않은 Stateless 방식의 요소라면 Active-Active를 비교적 쉽게 구현할 수 있습니다. 대표적인 예로 웹 서버에서 로컬 스토리지나 임시 파일등을 이용하지 않은 경우에 간단하게 구현할 수 있습니다. 기본적으로는 Active-Active가 가능하도록 최대한 Stateless로 해야하지만 데이터베이스 서버나 파일 서버 등 데이터를 저장하는 부분을 Active-Active로 하면 대개 데이터 정합성 유지를 위해 동기화가 필요하기 때문에 동작이 느려집니다.

다중화 구조

데이터의 정합성을 얻기 위한 방법

다중화한 경우의 주의할 점은 같은 데이터가 여러 개 존재하는 것이므로 어떤 데이터가 올바른 것인지 또는 가장 최신의 것인지를 제대로 관리해야 한다는 것입니다. 또한 여러 개의 데이터가 정확하게 일치하고 있는 상태를 유지해야만 합니다.

일반적으로 스토리지를 공유하는 Shared Disk 방식과 스토리지를 공유하지 않는 Shared Nothing 방식이 있습니다. 

Shared Disk 방식은 하나의 스토리지를 공유하며 대개는 전용 스토리지 기기를 이용합니다. Shared Disk 방식은 스토리지를 공유하기 때문에 정합성에 대해 특별히 문제될 것이 없습니다. 다만, Shared Disk 자체를 다중화해야 한다는 과제가 남습니다. Shared Disk 기능이 있는 스토리지 기기는 대체로 값비싼 기기들 입니다.



Shared Nothing 방식의 경우는 스토리지 간 통신을 해 데이터 정합성을 확보합니다. 이것을 리플리케이션이라 하며, 리플리케이션의 데이터 송신측을 master, 데이터 수식 측을 slave라고 합니다. multi-master라고 하여 각각이 master와 slave의 역할을 모두 갖는 방식도 있지만 문제가 많이 발생하기 때문에 잘 사용하지 않습니다.


동기식 리플리케이션은 오버헤드가 큰(동기 처리에 따른 성능 저하의 정도가 큰) 대신 데이터의 정합성을 확보하기 좋은 반면, 비동기식은 데이터 손실이 발생할 수도 있지만 성능 저하의 정도는 작습니다.

스토리지에 RDBMS(관계 데이터베이스 관리 시스템)를 사용할 경우, MySQL이나 PostgreSQL은 표준으로서 비동기 리플리케이션에 대응하고 있기 때문에 자주 사용됩니다. 또한, 파일의 경우는 Isyncd 등을 이용한 순차 동기가 주로 사용됩니다. 비동기 방식이라고는 하지만 대부분 수 초에서 수십 초 사이에는 반영이 완료됩니다.


위의 그림처럼 RDBMS에 데이터 손신을 피하는 리플리케이션 방법이 구현되었습니다. MySQL에서는 5.5버전부터 준동기식 리플리케이션이라는 명칭으로, PostgreSQL에서는 9.1버전부터 동기식 리플리케이션이라는 명칭으로 구현되고 있습니다. 명칭은 다르지만 구현하고 있는 기능은 거의 동일합니다.

이것은 데이터 손실은 없지만 Standby측의 데이터 반영까지는 동기적이지 않은 방식입니다. 데이터 보호의 관점에서는 동기식 또는 준동기식이 필수지만, 부분적으로 비동기식을 조합하여 전체 성능을 높이는 방법이 많습니다.



'서버' 카테고리의 다른 글

[docker] jenkins 설치  (0) 2016.09.24
[docker]우분투 docker 설치  (0) 2016.09.24
서버 다중화 (Active-Active, Active-Standby)  (0) 2016.08.25
x86 서버, 블레이드 서버, 랙 마운트 서버  (0) 2016.06.25
젠킨스란?  (0) 2016.06.20
cron, crontab - 작업 예약 명령  (0) 2016.01.23

x86 서버란

x86서버란 데이터센터내의 각 서버

x86서버는 x86 CPU를 기반으로 작동하는 서버를 말한다. x86 CPU는 과거에는 PC를 위해 만들어졌는데, 시간이 흐른 뒤에 서버에서도 사용되기 시작했다. PC보다 작업량이 많은 서버에서 x86 CPU는 제 역할을 하지 못했다. 불안정하고 오류가 쉽게 발생했기 때문이다. 그러던 중 인텔이 아예 서버와 워크스테이션을 위한 CPU ‘제온’을 출시하면서 x86서버 기능은 조금씩 나아지기 시작했다. AMD에서도 ‘옵테론’과 같은 서버용 CPU에 투자하기 시작했다. 이러한 기술 발전 때문에 x86서버는 성능이 향상됐고, 서버 시장에 주류 제품군으로 자리잡고 있다.

x86 서버의 주요 형태는 블레이드와 랙마운트가 있다.


x86서버 vs 유닉스 서버

서버 시장은 크게 x86 서버 시장과 유닉스 서버 시장으로 나뉜다. 유닉스 서버란 유닉스 운영체제(OS)를 기반으로 작동하는 서버를 말한다. 현재 유닉스 서버에서 사용하는 CPU 칩셋은 IBMHP, 오라클 등이 만들고 있다. 최근에는 가상화 기술이 보편화되면서 x86 서버나 유닉스 서버에 올라가는 운영체제는 거의 비슷해졌다. 두 서버의 가장 큰 차이점은 아무래도 가격이다. 보통 x86 서버는 ‘보급형 서버’로 불릴만큼 저가에 제공되고 있다. x86 서버가 수백만원대라면, 유닉스 서버는 수천만원을 호가한다. x86 서버와 유닉스 서버는 가격 차이만큼 성능에도 큰 차이가 난다. 오류가 나면 안 되는 핵심적인 기능, 일명 ‘미션 크리티컬’한 기술을 위해선 대부분 유닉스 서버가 쓰인다. x86서버는 대부분 큰 성능을 필요하지 않는 부분에서 저렴하게 이용할 수 있는 서버로 자리 잡았다. 처음 시장점유율은 유닉스 서버가 x86 서버보다 높았다. 이는 과거 메인프레임 서버와 유닉스 서버의 경쟁과 비슷한 구도다. 메인프레임 서버는 유닉스 서버보다 보안과 안정성이 높아 많이 쓰였다. 가격도 메인프레임이 유닉스 서버보다 훨씬 고가였다. 하지만 2천년대에 들어와 유닉스 기술력이 높아지면서 메인프레임이 있던 자리를 유닉스 서버가 점차 차지하게 됐다. 비슷한 현상이 x86 서버와 유닉스 서버에도 나타나고 있다. 많은 기업들이 IT 예산을 줄이면서 아무리 성능이 좋아도 비싼 제품을 함부로 구매하기 힘들어졌다. 이로 인해 저렴한 제품을 찾게 됐고 x86 서버가 각광을 받게 됐다. 서버 기술은 점점 좋아지고, x86서버 안정성도 초창기 시절보다 높아졌다. 한국은 해외보다 유닉스 시장이 더 강세를 보이는 나라다. 한국IDC에 따르면 글로벌 서버 플랫폼의 x86 시장점유율은 대략 70%인데, 국내에선 50% 정도다. 특히 안정성을 중시하는 금융권에서는 아직 유닉스가 인기이다. 그럼에도 국내에서는 2011년부터 유닉스 서버와 x86 서버간의 시장점유율이 점점 좁아지더니, 2012년에는 x86 서버 시장점유율이 유닉스 서버를 앞섰다. x86 서버는 저렴한 가격, 저전력이라는 장점이 있다. 대량으로 사용할 때 경제적이며 에너지 절감도 된다. x86 서버는 저렴한 가격, 저전력이라는 장점을 내세워 시장에서 점유율을 늘려가고 있다. 유닉스 시장은 경기불황으로 더 침체됐다. 시장 전체적으로 대형 프로젝트나 고성능을 필요로 하는 서버를 새로 구매하는 일이 줄어들었기 때문이다. 가트너가 발표한 ‘2014년 2분기 서버 출하량 보고서’에 따르면 x86 서버의 경우 2014년 2분기 출하량은 1.4%, 매출은 8.1% 증가했다. 반면 유닉스 서버는 해당 분기 동안 전세계적으로 침체된 양상을 보여 전년동기 대비 출하량은 23.2%, 매출은 7.9% 감소했다. 또한 유닉스는 시스템 확장이나 추가 개발 시 비용이 많이 들지만, x86 서버는 분산형으로 추가할 수 있어 확장성이 높다. 최근 소프트웨어 정의 기술이 인기를 끌면서, 굳이 좋은 하드웨어를 쓰지 않아도 소프트웨어로 부족한 기능을 채울 수 있게 됐다. 이러한 환경에 힘입어 x86 서버 시장은 점점 성장하고 있다.

블레이드 서버란

블레이드서버는 모든 인프라를 쉽게 관리할 수 있다. 자세하게 블레이드 서버는 한 박스에 서버와 네트워크를 축소시켜 통합하고 운영체제를 사전 설치해 공급된다. 블레이드 서버는 하나의 장비 자체가 완성된 서버다. 블레이드 서버의 가장 큰 장점은 작은 크기다. 같은 공간에서 랙마운트 서버보다 더 고집적 환경을 만들 수 있다. 모든 서버를 중앙집중화된 환경에서 관리할 수 있다는 장점도 있다. 단일 인터페이스로 서버 프로파일 작성, 네트워크 생성, SAN 추가, 가상LAN 설정, 전원 관리 등을 통합관리할 수 있다. 인프라가 통합되는 만큼 서버업체에서 제공하는 차별화된 기능의 효과를 극대화할 수 있다. 이러한 장점에 비해 블레이드 서버의 단점은 무엇보다 비싼 가격이다. 장비 한대의 가격을 비교하면 랙마운트보다 확실히 비싸다. 블레이드 서버를 위해 특별히 제작된 전원 연결도 필요하다. 또한 특정 제조업체에 종속된다는 점도 단점으로 통한다. 섀시나 인클로저가 제조업체별로 규격을 다르게 만들어지기 때문이다. 그래서 블레이드 서버는 여러 제조업체 제품을 혼용하는 게 불가능하다. 관리자 입장에서 생기는 불편함도 있다. 블레이드는 전원을 켠 상태에서 네트워크나 SAN 연결을 추가하거나 삭제하는 게 불가능하다. 랙마운트 서버에 익숙한 사람에게는 블레이드는 셋업 과정이 불편할 수 있다. 여러 대의 서버를 집적할 수 있다는 점은 장점이면서 단점이다. 한 공간에 여러 대의 서버를 모아 놓기 때문에 그 하중이 랙마운트보다 높다. 블레이드는 랙마운트보다 2배의 집적도를 보이는데, 완벽히 채워진 2개의 인클로저는 400킬로그램(kg) 이상의 무게를 자랑한다.

랙 마운트 서버란

랙 마운트 시스템은 사용자에게 자유롭다. 자세하게 랙마운트 서버는 규격이 표준화되어 있다. 표준 랙마운트 서버는 일반적으로 19인치 랙에 1U, 2U, 4U 크기의 서버를 장착하게 된다. 별도의 전원과, 네트워크, SAN 스위치 등을 연결한다. 랙마운트 시스템의 이점은 블레이드와 정반대다. 네트워크나 디스크, 전원 등의 구성요소가 플러그앤플레이로 작동한다. 시스템의 물리적 변경을 위해 하드웨어 전원을 끌 필요가 없다. 설치 소프트웨어, 운영체제 등을 담은 DVD를 이용하기 위한 DVD 드라이브도 장점으로 통한다. 블레이드에 비해 더 독립적이고 자유롭다는 점도 장점이다. 19인치 랙 어디에나 서버를 장착할 수 있다. 별도로 제작된 와이어, 전원, 인클로저가 아닌 표준 부품으로 환경을 구축할 수 있다. 가격도 블레이드 서버보다 싼 편이다. 랙마운트 서버의 단점은 물리적인 작업의 어려움이다. 랙 하나를 다 채웠을 때 무언가 수작업을 하려면 복잡한 과정을 거쳐야 한다. 일단 뚜껑을 제거한 후, 모든 것의 플러그를 뽑고, 시스템을 밖으로 꺼낸 후 작업을 해야 한다. 다시 장착할 때 이 과정을 역순으로 반복한다. 대부분의 랙마운트 서버는 각종 포트와 물리적 작업 영역이 후면에 위치한다. 발열 문제도 있다. 랙마운트 서버는 블레이드에 비해 불필요한 발열이 더 많다. 더 많은 냉각 장치가 필요하며 서버랙 배열도 공기통풍에 더 공학적으로 접근해야 한다.

블레이드와 랙 마운트 서버 선택

블레이드 서버는 밀도있는 서버 환경을 구축할 필요가 있고, 무게를 견딜 수 있는 경우 선택하는 게 유리하다. 블레이드 관리에 대한 기술에 익숙해야 하며, 블레이드 운영 시 발생하는 여러 불편함을 감수해야 한다. 랙마운트 서버는 적은 예산으로 구축해야 하고 제조업체 종속을 원하지 않을 때 선택하면 된다. 중앙집중식의 관리 절차의 필요성을 느끼지 못할 때와 냉각, 전원, 통풍에 대한 절전설비가 충분할 경우 선택하는 게 좋다. 일단 서버업체들은 고객의 선택에 맡긴다는 입장이지만 자사의 기술력을 더 담아 차별화할 수 있는 블레이드 서버를 더 판매하길 원한다. 서버업체 관계자는 “블레이드 서버는 단일 제품의 가격은 비싸지만 대규모로 확장할수록 들어가는 비용이 줄어든다”라며 “적절한 환경에 따라 블레이드와 랙형을 구분하고 혼용하는 것을 추천한다”라고 말했다

젠킨스를 통해 지속적인 통합 (CI: Continuous Integration)을 행할 수 있다.


형상관리(git, 서브버전 등)와의 연동

젠킨스와 같은 CI툴이 등장하기 전에는 일정시간마다 빌드를 실행하는 방식이 일반적이었다. 특히 개발자들이 당일 작성한 소스들의 커밋이 모두 끝난 심야 시간대에 이러한 빌드가 타이머에 의해 집중적으로 진행되었다. 젠킨스는 정기적인 빌드에서 더 업그레이드 해 서브버전, Git와 같은 버전관리 툴과 연동하여 소스의 커밋을 감지하면 자동적으로 자동화 테스트가 포함된 빌드가 작동되도록 설정 할 수 있다. 개발 도중의 커밋은 빈번하게 일어나기 때문에 커밋 횟수만큼 빌드를 실행하는 것이 아니라 큐잉되어 자신이 실행될 차례를 기다리게 된다. 
 코드의 변경과 함께 이뤄지는 자동화 빌드와 테스트 작업들은 다음과 같은 이점들을 가져다 준다.
  • 프로젝트 표준 컴파일 환경에서의 컴파일 오류 검출
  • 자동화 테스트 수행
  • 정적 코드 분석에 의한 코딩 규약 준수여부 체크
  • 프로파일링 툴을 이용한 소스 변경에 따른 성능변화 감시
  • 결합 테스트 환경에 대한 배포작업

이 외에도 젠킨스는 500여가지가 넘는 플러그인을 온라인으로 간단히 인스톨 할 수 있는 기능을 제공하고 있으며 파이선과 같은 스크립트를 이용해 손쉽게 자신에게 필요한 기능을 추가 할 수도 있다.

 

각종 배치 작업의 간략화

프로젝트 기간 중에 개발자들은 순수한 개발 작업 이외에 DB셋업이나 환경설정, deploy 작업과 같은 단순 작업에 시간과 노력을 소비하는 경우가 빈번하다. 데이터베이스의 구축, 어플리케이션 서버에 deploy,  라이브러리 릴리즈와 같이 이전에 커맨드 라인 인터페이스로 실행되던 작업들이 젠킨스 덕분에 미려한 웹 인터페이스로 손쉽게 가능해지게 되었다.

 

젠킨스은 거들뿐

이와같이 다양한 작업들을 손쉽게 처리해 주지만 테스트를 만들고 빌드 전략을 세우는 등의 작업은 여전히 개발자의 몫으로 남아 있다. 젠킨스가 진정으로 프로젝트에 도움이 되기 위해서는 다음과 같은 작업이 반드시 함께 이루어 져야 한다.

Build 자동화의 확립

빌드 툴의 경우 Java는 이미 Maven이 대세로 자리 잡았다. 물론 Ant도 훌륭한 기능들을 많이 갖추고 있지만 플러그인의 편리함은 Maven을 따라잡지 못한다. 이미 빌드관리 툴을 이용해 프로젝트를 진행하고 있다면 Jenkins를 사용하지 않을 이유가 하나도 없다.

 

자동화 테스트

자동화 테스트는 젠킨스를 사용해야 하는 이유 중 하나이며, 사실상 자동화 테스트가 포함되지 않은 빌드는 CI자체가 불가능하다고 봐도 무방하다. 젠킨스는 Subversion이나 Git와 같은 버전관리 시스템관 연동하여 코드변경을 감지하고 자동화 테스트를 수행해 줌 으로서 만약 개인이 미처 실시하지 못한 테스트가 있다 하여도 든든한 안전망이 되어준다. 무엇보다 중요한것은 이러한 안전망이 제공해 주는 안심감이야 말로 개발자들이 악취나는 코드를 리팩토링을 통해 적극적으로 제거 할 수 있게 해 주는 든든한 버팀목이 된다는 점이다.

 

테스트 커버리지

젠킨스는 자동화 테스트 실시와 더불어 테스트 커버리지도 리포팅을 해 준다. 

코드 표준 준수여부 검사

 자동화 테스트와 마찬가지로 개인이 미처 실시하지 못한 코드 표준 준수여부의 검사나 정적 분석을 통한 코드 품질 빌드 내부에서 수행하는 것으로서 기술적 부채의 감소에도 크게 기여한다.

 빌드 파이프라인 구성

2개 이상의 모듈로 구성되는 프로젝트의 경우 당연하게도 레이어드 아키텍처가 적용되어 있을터이고 그에 따른 빌드 파이프라인 구성이 필요하다. 예를 들자면 도메인 -> 서비스 -> UI와 같이 각 레이어의 참조관계에 따라 순차적으로 빌드를 진행하지 않으면 안된다. 이러한 파이프라인의 구성은 선형 뿐만 아니라 간단한 스크립트를 통해 매우 복잡한 제어 까지도 가능하다. 


개요

cron(크론)은 원하는 시간에 명령(프로그램)을 시키기 위한 데몬입니다. 서버는 늘 깨어있다는 것을 이용한 최대한의 활용법입니다. cron을 사용하는 이유는 사람이 직접 서버에서 특정 작업을 매일 할 수 없기 때문입니다. 예를 들어, 새벽 3시에 매일 서버에서 작업을 해야하는 경우나, 30분 간격으로 CPU 사용량을 운용자에게 알리는 경우 사람이 직접 하는 것에 한계가 있어 cron을 사용하게 됩니다. cron은 항상 지정한 시간이 되었는지 확인하면서 해당 명령어를 실행합니다.

동작원리

crontab은 멀티쓰레드 환경으로 동작하지 않습니다(아마도). 모든 cron은 하나의 작업 또는 다른 작업을 실행할 시간이 될 때까지 시간을 간결하게 표현하는 작업을 수행해야 합니다. 그렇다면 해당 작업을 실행하는 프로세스를 포크하고 작업이 완료되었는지 주기적으로 확인하여 정리해야만 합니다. 멀티쓰레드 환경이 이러한 대기환경을 위해 사용될 수는 있지만 배보다 배꼽이 더 크다고 생각합니다. wait () / waitpid() 함수를 사용하면 즉시 모든 자식 프로세스들를 볼 수 있습니다 . 차단하지 않고도 한눈에 확인할 수 있으므로 다음 작업을 실행할 시간을 계속 찾고 있을 가능성이 있습니다. 그리고 SIGCHLD도 존재합니다.

설정방법

cron 설정 자체는 /etc/crontab에서 합니다. 사용자는 해당 파일에 실행하고자 하는 프로세스를 간편하게 아래와 같은 옵션을 사용하여 추가, 삭제 등을 할 수 있습니다.

옵션

$ crontab -e  # 설정된 파일을 새롭게 편집 - 맨 처음에 사용할 편집기를 고를 수 있음
$ crontab -d  # 등록된 내용을 삭제
$ crontab -l  # 현재 등록된 리스트 출력
$ crontab -l -u otheruser  # otheruser 사용자가 등록한 crontab 리스트 출력
$ crontab -r  # 현재 사용자가 등록한 crontab 전체 삭제

crontab -e로 프로세스를 추가, 삭제 및 수정을 하고 저장하고 에디터 창을 빠져나가면 바로 적용이 됩니다.

crontab에 적용된 리스트가 없을 경우 아래와 같은 문구가 출력됩니다.

$ crontab -l
no crontab for root

사용자 허용 및 거부

특정 사용자가 crontab을 사용하지 못하게 할 경우나 사용하게 하고 싶은 경우 아래와 같이 수정합니다.

$ vi /etc/cron.allow # 허용할 사용자 ID 추가
$ vi /etc/cron.deny # 거부할 사용자 ID 추가

파일형식

필드의미범위
첫번째0~59
두번째0~23
세번째0~31
네번째1~12
다섯번째요일0~7 (0 또는 7 일요일, 1= 월요일, 2=화요일, ...)
여섯번째명령어실행할 명령어를 한줄로 작성

표현필드

문자의미예시
*해당 필드의 모든 시간을 의미

* * * * * ./test.sh

매일, 매시 1분단위로 test.sh를 실행 (하루에 1440회)

콤마(,)여러 시간대를 지정할 수 있음

10,20 * * * * ./test.sh

매일, 매시 10분, 20분 마다 test.sh를 실행 (하루에 48회)

하이픈(-)시간을 범위로 지정할 수 있음

* * * 3-5 * ./test.sh

3월~5월까지 매시간 매분에 test.sh를 실행

슬래쉬(/)시간의 간격을 지정할 수 있음

*/10 * * * * ./test.sh

10분마다 test.sh를 실행

주의점

  • 한 줄당 하나의 명령 (두 줄로 나눠서 표시할 수 없음)
  • 주석처리는 실행되지 않음 (당연)
  • 모든 엔트리 필드는 공백으로 구분

한 줄로 여러 명령을 실행하고자 하면 쉘스크립트를 만들어 해당 스크립트 파일을 실행 하던지 다중 명령어인 &&를 사용해야 합니다.

예시

crontab -e를 치고 에디터를 고르면 (아래는 vi) 다음과 같은 화면을 볼 수 있습니다.

# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h dom mon dow command

위 화면에 아래와 같은 예시들을 추가한 다음 저장하면 crontab 설정이 자동으로 등록됩니다.

* * * * * /root/cronTest.class # 매 1분마다 /root/cronTest.class를 수행 (하루에 1440회)
15,45 * * * * /root/cronTest.class # 매시 15분, 45분에 /root/cronTest.class를 수행 (하루에 48회)
*/10 * * * * /root/cronTest.class # 10분마다 /root/cronTest.class를 수행 (하루에 144회)
0 2 * * * /root/cronTest.class # 매일 02:00에/root/cronTest.class를 수행 (하루에 1회)
30 */6 * * * /root/cronTest.class # 매 6시간마다 수행(00:30, 06:30, 12:30, 18:30)
30 1-23/6 * * * /root/cronTest.class # 1시부터 매 6시간마다 수행(01:30, 07:30, 13:30, 19:30)

로그

보통 crontab의 로그는 /var/log/cron 위치에 존재하지만 우분투 14.04 LTS의 경우는 해당 위치에 존재하지 않습니다.  /var/log/syslog 위치에 crontab의 로그가 존재합니다. 좀더 편하게 보는 방법은  sudo tail -F /var/log/syslog의 명령어를 사용하여 실시간으로 확인할 수 있습니다.

$ sudo tail -F /var/log/syslog Dec 20 15:04:29 DEV-F1-SERVICE-001 kernel: [705029.840187] IN= OUT=eth0 SRC=172.16.114.69 DST=91.189.95.15 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=61267 DF PROTO=TCP SPT=55124 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0 Dec 20 15:05:01 DEV-F1-SERVICE-001 CRON[27732]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) Dec 20 15:07:22 DEV-F1-SERVICE-001 crontab[27756]: (test) LIST (test) Dec 20 15:09:19 DEV-F1-SERVICE-001 crontab[27786]: (test) DELETE (test) Dec 20 15:09:23 DEV-F1-SERVICE-001 crontab[27787]: (test) LIST (test) Dec 20 15:12:19 DEV-F1-SERVICE-001 crontab[27818]: (test) BEGIN EDIT (test) Dec 20 15:12:34 DEV-F1-SERVICE-001 crontab[27818]: (test) REPLACE (test) Dec 20 15:12:34 DEV-F1-SERVICE-001 crontab[27818]: (test) END EDIT (test) Dec 20 15:15:01 DEV-F1-SERVICE-001 CRON[27847]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1



 OS

 Virtual box

 guest OS

 윈도우 10

 5.0.12

 우분투 14.04 LTS


먼저 virtual box(이하 vb라 부름)에서 우분투 14.04 LTS vm을 생성한 뒤, 설정 - 네트워크로 이동합니다.

다음에 연결됨의 속성을 브리지 어댑터로 변경하고 무작위 모드의 속성을 가상 머신에 허용으로 바꿉니다.

 

확인을 누른 후, 해당 vm 을 실행합니다.

 

아래와 같은 명령어를 쳐서 interfaces를 텍스트 편집기로 실행합니다.

1
$ sudo vi /etc/network/interfaces 
cs

 

정상적으로 열렸을 시, 아래와 같이 보입니다.

# This file describes the network interfaces available on your system

# and how to activate them. For more information, see interfaces(5).

# The loopback network interface

auto lo

iface lo inet loopback

# The primary network interface

auto eth0

iface eth0 inet dhcp

 

이 내용들을 다음과 같이 수정 및 추가해줍니다.

# This file describes the network interfaces available on your system

# and how to activate them. For more information, see interfaces(5).

# The loopback network interface

auto lo

iface lo inet loopback

# The primary network interface

auto eth0

iface eth0 inet static

address 10.101.30.124

gateway 10.101.30.1

netmask 255.255.255.0


address는 해당 vm에서 사용할 ip입니다.

gateway는 address 대역대에서 (x.x.x.1)을 gateway로 지정합니다. 

netmask는 255.255.255.0으로 설정합니다.

저장을 한 다음, 아래의 명령어를 실행시키면 다음과 같이 보입니다.

$ sudo vi /etc/resolv.conf

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)

#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

 

여기에 nameserver를 추가시킵니다.

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)

#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN4

nameserver 164.124.101.2

 

고정 IP를 사용하는 것이 아닌 유동 IP를 사용할 때 nameserver는 보통 168.126.63.1을 적으면 사용 가능합니다.


다음 vm을 재부팅 시키면 ip가 변경된 것을 확인할 수 있습니다.


여기서 vm의 ip를 변경하고 아웃바운드가 가능하게 하려면 로컬에서 cmd를 실행시켜 잡혀있는 서브넷마스크, 게이트웨이, 동일한 대역대의 ip로 설정해야 합니다.

 

 



+ Random Posts