Type and press Enter.

가상 서버를 운영하고픈 勇者에게 전하는 가상 서버 운영 입문 노하우 – Vultr 가상서버호스팅(VPS)를 중심으로

Vultr에서 가상서버호스팅을 운영하고 있고 이에 대한 경험을 주제로 포스팅을 몇번 올렸는데요. 이를 보고 가상 서버 호스팅 운영에 대해서 문의하는 분들이 있었습니다.

최근 웹서비스 환경이 바뀌면서 가상서버호스팅에 대한 관심이 높아졌습니다. 심지어 최근 암호화폐 광풍이 몰려오면서 Vultr같은 가상서버호스팅을 암호 화폐 증식(증식이라는 단어를 사용한 이유는 채굴에는 어마어마한 전기료와 시스템이 소요되기에 가상서버에서는 거의 불가능하고, 일부 화폐의 경우 증식하는데 가상 서버를 사용한다고해서 이 단어를 골랐습니다.)에 활용되는 사례조차 나오는 것 같습니다.

“가상 서버를 운영하고픈 勇者에게 전하는 가상 서버 운영 입문 노하우 – Vultr 가상서버호스팅(VPS)를 중심으로”라는 제목을 단 이유는 일반 웹호스팅을 이용하다가 가상서버호스팅(VPS)로 옮기려는 분들에게 도움이 되도록 보다 쉽고 간결하게 가상서버호스팅에서 워드프레스 등 사이트를 운영하는 방법에 대해 이야기 해보자는 목적이 있습니다.

그래서 그 동안 Vultr에서 가상서버호스팅을 했던 경험을 토대로 가상서버로 (워드프레스) 사이트 운영 노하우를 정리, 공유해 보고자 합니다.

1. 가상 서버 호스팅이란?

여기에서는 가상 서버 호스팅이 다른 웹호스팅 또는 단독 호스팅과 어떻게 다르고 그 자체의 의미를 짚어보고, 관련 업계에 대해 정말 간단하게 살펴 보겠습니다.

1.1. 가상 서버 호스팅 정의

사이트를 운영하려면 사이트를 구축할 장소가 필요한데요. 이 구축 장소에는 wordpress.com과 같이 특정 서비스에 가입하는 방법, 호스팅만 전문으로 해주는 웹호스팅 이용 방법(Shared hosting), 가상 서버 호스팅(VPS, Virtual Private Server), 단독 서버 방식(Dedicated Server)이 있습니다.

이중 서버 호스팅(VPS)은 물리적인 서버를 가상화하여 각각의 가상 서버를 사용자에게 제공하는 방식으로, 물리 서버 한대에 여러 가상 서버를 입주시키게 됩니다. 기서 물리 서버 한대에 얼마나 많은 가상 서버를 입주시키느냐가 안정적인 성능의 관건이죠. 업체 이익을 생각한다면 한개의 서버당 최대한 많은 가상서버를 입주시키는게 좋겠죠. 그렇지만 입주한 사용자 사이트 성능과 관계가 되므로 성능에 영향를 주지 않으면서도 가장 많은 가상 서버를 입주시킬 수 있는 역량이 중요합니다.

▽ 가상 서버 개념을 아주 거칠게 표현하고 있는 사진,
이미지는 고대디에서 빌려 왔다.

가상 서버 이미지 고대디

1.2. 가상 서버 호스팅 업체는?

이러한 가상 서버를 제공하는 업체에는 어디가 있을까요?
인터넷이나 IT서비스가 클라우드 방식으로 이동하고 관련 기술이 발전하면서 이에 대한 수요가 증대하면서 관련 업체가 급속히 늘어나고 있습니다.

저눈 2016년 웹호스팅을 운영하다가 가상 서버 호스팅으로 갈아탔는데요. 이 당시 국내는 쓸만한 가상 서버호스팅이 많지는 않았습니다.
성능과 가격 경쟁력이 우수한 업체는 주로 외국에 있습니다. 한국 업체는 상대적으로 비쌌고 자율권도 상당히 부족했었습니다. 가상서버호스팅으로 갈아 타기 위해 엄청난 검색을 통해 내린 결론은 Linode, Vultr, DigitalOcean, 코노하가 쓸만하고 특히 도쿄에 서버가 위치한 Linode와 Vultr가 우수하며 코노하는 매력적이긴 하지만 일정 용량이 넘으면 트래픽 제한같은 보이지 않는 장애가 있다는 평이었습니다.

2018년 1월 현재 cafe24, IwinV(구 스마일서브)와 같은 나름 가격 경쟁력을 가진 국내 업체들이 등장했습니다. 구체적인 서비스를 따져보면 아직 경쟁력이 부족하지만 국내라는 강력한 장점을 가지고 있어 국내도 시도해볼 만한 것 같습니다. 다만 아직은 기술력이 부족해 전문적으로 사용하기는 어렵다는 평도 있습니다.

IwinV에 대해서는 iwinv 클라우드 서버 사용후기 와 그에 딸린 댓글을 참조해 보세요.

여러 가상 서버 호스팅 업체를 다 경험해보지 않아서 각 업체별 평가는 라엘님의 국내 클라우드 서버호스팅 비교(Virtual Private Server Review)를 참조하시면 좋을 것 같습니다. 저도 여기를 보고 vultr에 관심을 가졌고 여러 검토한 끝에 Vultr을 선택했습니다. 당시 많은 추천을 받았던 Linode는 도쿄에 여유가 없었습니다.

해외 가상 서버 호스팅업별 서버 위치별 핑속도, 다운로드 속도를 한거번에 비교해 볼 수 있는 사이트가 있습니다. 바로 cloudharmony.com인데요. 구체 내용은 아래 포스팅을 참조하세요.

클라우드 및 가상서버호스팅 업체별 속도 비교 사이트 cloudharmony.com 소개

한편 Vultr을 사용 후 간략히 정리했던 아래 사용기를 참조해 보시기 바랍니다.

가성비가 뛰어난 Vultr 가상서버호스팅(클라우드호스팅,VPS) 사용기

2. Vultr 가상 서버 호스팅 등록 및 설치

먼저 Vultr 가상 서버 호스팅을 이용하기 위해서는 가입을 합니다. 가입 시 포로모션 쿠폰을 적용하면 일정 금액을 절약할 수 있는데요. 예전엔 프로모션을 굉장히 많이해 20$, 30$ 쿠폰이 많았지만 최근에는 공식적인 10$ 쿠폰조차 없어졌습니다. 다만 기존 사용자의 추천 쿠폰으로 가입하는 경우 10$ 프로모션은 여전히 살아 있습니다.

필요하면 아래 10$ 프로모션 쿠폰으로 가입합니다.

10$ 제휴 프로모션으로 Vultr 가입하기

3. 서버 설치

Vultr에 가입했으면 이제 본격적으로 서버 세팅을 해 봅니다. Vultr에서는 개개의 서버를 Instance라고 부릅니다. 서버 세팅, Vultr에서 이야기하는 Deploy New Instance 화면의 Vultr Cloud Compute(VC2)화면에서 세팅을 시작할 수 있습니다.

아래는 간단히 서버 세팅 과정을 보여주고 있습니다.

3.1. 서버 위치 선택

서버 위치는 2018년 1월 현재 글로벌로 15군데가 있는데요 아시아권에는 일본 도쿄와 싱가폴에 있습니다. 속도는 고려하면 당연히 도쿄를 선택합니다.

▽ 서버 위치를 설정 장면

Vultr 설치_설치 지역 선택 2018-01-19 at 20.04.04

3.2. 서버 운영 체제

이번에는 서버 운영 체제를 선택합니다.
서버를 선택, 설치하는데에는 여러가지 방법이 있는데요. 아래를 보시면 알겠지만 굉장히 다양한 방법을 제공하고 있습니다.

3.2.1. Vultr에서 제공하는 서버 운영 체제 설치 방법

첫째, 일반 프로그램 설치하듯이 자신에게 맞는 운영 체제를 선택해 설치하고, 이어서 필요한 프로그램을 설치하는 방식
둘째, Application이라고 해서 운영체제 + 제반 프로그램을 일괄 설치하는 방법
셋째, 다른 곳에서 만들어 놓은 ISO 파일을 업로드해서 그대로 사용하는 방법
넷째, Vultr에서 제공하는 ISO 파일을 그대로 사용하는 방법
다섯째, 이미 Vultr을 이용하는 상태라면 유료로 백업 서비스를 받고 있다면 이 백업 파일로부터 서버를 생성하는 방법
여섯째, 이미 Vultr을 이용하는 상태라면 기존에 만들어 놓은 Snapshot으로 그대로 서버를 떠주는 방법

Application 설치 방식은 운영 체제과 관련 프로그램을 한꺼번에 설치해주므로 편하긴 하지만 원하는 프로그램을 선택할 수 없고 최신 프로그램은 지원하지 않은 경우가 많습니다. 예를 들어 wordpress 설치 Application은 Centos 6만 가능합니다. Ubuntu를 선택하고 싶다거나 Centos 7을 설치하고 싶으면 사용할 수 없지요.

전문가라면 다른 곳에서 만들어 놓은(제대로 잘 세팅된) ISO를 업로드 하는 것도 괜찬을 겁니다. 그렇지만 초심자에게는 너무 먼 이야기이지요.

Vuktr에서 제공하는 ISO는 일반 프로그램 설치와 거의 같은 방식입니다.

따라서 저는 일반 프로그램처럼 설치하는 첫번째 방식을 사용했습니다.

3.2.2. 32비트? 64비트?

윈도우즈도 32비트 64비트가 있듯이 리눅스계열도 32비트와 64비트로 나누어져 있습니다. 그래서 64비트를 설치할것인지, 32비트를 설치할 것인지를 선택해야 합니다.
일반적으로 RAM이 512MB, 765MB 적을 경우 32비트를 설치하는 게 좋다고 하네요. 32비트가 최소 메모리를 사용하기 때문이라고 합니다.
그리고 최소 1GB정도 되어야 64비트가 아주 원활합니다. 실제로 워드프레스 등 운영 시 최소 메모리를 1GB로 권장하고 있습니다.

3.2.3. 어떤 운영 체제, 어떤 버젼을 선택할 것인가?

운영체제를 무엇으로 할것인지도 고민인데요. 센토스나 우분투등이 일반적으로 많이 사용되므로 둘중 하나를 고르면 됩니다. 저는 최근 뜨고 있다는 우분투를 선택했습니다.

우분투 버젼을 선택해야하는데, 우분투는 14.04, 16.04 그리고 올해 나온다는 18.04가 5년을 지원하는 LTS 버젼이므로 가능하면 이를 선택하라고 조언하고 있습니다. 현재는 18.04가 아직 나오지 않았으니 16.04를 설치하는 게 좋겠지요.

그러나 저는 사이트가 작고 종종 서버를 다시 설치하므로 지원 기간보다는 최신 버젼에 방점을 찍고 가장 최신 버젼인 17.10을 설치했습니다.

Vultr는 항상 최신 버젼을 설치할 수 있도록 빠르게 대응하고 있습니다. 국내 서버 업체들을 보면 대부분 최신 버젼을 지원하지 않는데요. 최신 버젼에 민감하고 이를 빨리 테스트해보고 싶다면 그런 의미에서 Vultr도 좋은 대안이 될 듯 하네요.

▽ 서버 타입 선정 화면 – 64비트 운영체제 중 우분투 17.10을 선택

Vultr 설치_서버 운영 체제 결정 서버 타입 결정

▽ 서버 타입 선정 화면 – Application을 중심으로 선택, 설치 할 수 있다.

Vultr 설치_Application 2018-01-19

▽ 서버 타입 선정 화면 – Vultr에서 제공하는 ISO List에서 선택, 설치할 수 있다.

Vultr 설치_Vultr ISO List 2018-01-19

3.3. 플랜 결정 – 서버 크기

이 단계에서는 가장 중요한 가격대를 선택해야 합니다.
국내의 많은 웹호스팅과 마찬가지로 상위 플랜으로 업그레이드는 가능하지만 다운그레이드는 허용하지 않기 때문에 처음에는 당장 웅요할 수준 정도로 시작하고 점차 업그레이들 하면 좋습니다.

나중에 다시 정리하겠지만 상위 플랜으로 업그레이드는 서버를 유지한 채 버튼 하나만 눌러서 몇분내에 끝납니다. 아주 쉽고 간단합니다.

저는 데이타베이스 크기가 100MB 정도이고 하루 방문객이 5,000명이 안되기 때문에 처음에 5$ 플랜으로 시작했다가 더 많은 램을 활용하고 싶어서 10$짜리 40GB SSD, 1GB램으로 업그레이드 했습니다.

▽ 서버 크기를 선정 화면

Vultr 설치_설치 타입 가격 플랜 결정

3.4. 추가 기능 설정

이어서 추가 기능을 선택할 수 있습니다.

  • IPv6를 추가할 수 있고(무료)
  • 자동백업 선택(이는 요금 플랜의 20%가 붙습니다. 위에서 5$ 플랜을 선택 시 1$, 10$ 플랜을 선택 시 2$ 등)
  • DDOS Protection 항목이 있는데 이는 미국 일부 지역만 현재 가능하다고 함
  • Private Networking 선택, 이는 Vultr에 여러개 서버를 운영하는 경우 서버별 내부 IP를 할당받아 내부트랜지션을 할 수 있는 기능

▽ 추가 기능 선택합니다.
저는 혹시 몰라서 IPv6를 사용한다고 선택했습니다.

Vultr 설치_추가 옵션 설정 Addional Feature

3.5. 설치 스크립트

서버 설치 시 추가 프로그램등을 설치할 수 있도록 자동 스크립트를 지원합니다.

스크립트를 잘 짜면 서버설치 시간을 크게 줄일 수 있죠. 이는 전문가의 영역

Vultr 설치_설치 스크립트 Start Script

▽ 설치 시 추가 스크립트 설정 화면

Vultr 설치_Add Startup Script 2018-01-19 at 20.01.21

3.6. SSH keys, Host Name

▽ SSH keys, Host Name 설정

Vultr 설치_SSH Key 및 Hostname

여기까지 설정했으면 드디어 서버를 만들 준비가 끝났습니다.
맨 아래에 있는 Deloy Now 버튼을 누르면 드디어 서서가 생성되기 시작하며 단 몇분만에 서버 세팅이 완료됩니다.

3.7. 세팅 완료

▽ 드디어 서버 세팅이 끝났습니다.
이제 다른 프로그램을 설치하러 가야죠.

6단계 서버 설정 완료 deploy finish

3.8. 서버 상태 정보

▽ 최종 세팅한 서버의 상태 정보입니다.
보안을 위해서 일부 화면은 지웠습니다.

서버 정보

4. 서버 세팅 및 워드프레스 설치

다음 단계는 서버 세팅 단계입니다. 여기에서는 사이트를 운영하는 데 필요한 여러가지 프로그램을 설치합니다.

  • 웹서버(NGINX, Apache등) 설치
  • 데이타베이스(MySQL, MariDB등) 설치
  • PHP(PHP 5.x or PHP 7.x)

아래에서는 웹서버, 데이타베이스, PHP 버젼 선택에 대해 배경 설명을 해보겠습니다.

4.1.1. 웹서버 선택

웹서버를 위키백과에서 아래와 같이 정의하고 있습니다.

웹 서버(Web Server)는 HTTP를 통해 웹 브라우저에서 요청하는 HTML 문서나 오브젝트(이미지 파일 등)을 전송해주는 서비스 프로그램을 말한다. 웹 서버 소프트웨어를 구동하는 하드웨어도 웹 서버라고 해서 혼동하는 경우가 간혹 있다.

이러한 기능을 하는 웹서버에는 아파치(Apache), NGINX, 마이크로소프트 윈도우즈 등이 있는 데요.
NETCRAFT 자료를 보면 2017년 12월 기준, 활성화 되어 있는 웹사이트 기준으로 아파치(Apache) 42%, NGINX 23%, 마이크로소프트 윈도우즈 22%의 점유율을 점하고 있다고 합니다.

▽ 웹서버 점유율 추이 2017년 12월까지,
자료원 – NETCRAFT

웹서버 점유율 추이 2017년 12월까지

이중에서 NGINX가 가장 빠르게 성장하고 있는 웹서로 확인되고 있습니다. 위 그래프를 보면 2017년 12월 NGINX가 처음으로 마이크로소프트를 제치고 No 2가 되었습니다.

“NGINX가 작은 자원을 가지고 효율적으로 운영될 수 있어서 처름 시작하는 소규모 사이트에서 각광을 받고 있으며 아파치(Apache)는 기준 풍부한 운영 경험을 토대로 대규모 사이트에서 선호하고 있다.”고 합니다.

그런 의미에서 저는 참고 자료들이 상대적으로 적지만 자원 효율성이 좋다는 NGINX를 선택했습니다. 물로 아파치(Apache)도 NGINX에 대항하고자 고효율이 가능한 패치를 지속적으로 업데이트하고 있어 성능에서 NGINX가 확실하게 더 좋다고는 할 수 없다고 하네요. (그동안 주워들은 풍워로 이야기하면) 다만 세팅 등은 확실히 NGINX가 단순합니다. 그래서 초보들에게 더 맞습니다.

4.1.2. 데이타베이스 선택

이제 데이타베이스를 선택할 시간인데요. 우리나라에서는 MySQL이나 MariaDB를 많이 선택하는 것 같습니다.

MySQL 창업자인 마이클 와이드니어는 MySQL이 오라클에 인수되고 오라클에서 제대로 발전하지 못하자 독립해 MariaDB를 제안합니다. 이 MariDB는 MySQL과 호환되면서도 더 많은 운영체제를 지우너하고 더 진보된 기능을 넣어 성능을 개선 시키겠다는 목표로 출발했습니다.

사담으로 마이클 와이드니어의 첫째딸이 My이고 막내 딸이 Maria라고 하네요. 그래서 이름을 MySQL과 MariaDB라고 지었다고 합니다.

아무튼 오라클에 인수된 MySQL은 라이센스를 높이는 등 상업성을 강화했지만 강력한 지원에 힘입어 데이타베이스 업계에서 막강한 시장점유율을 유지하고 있습니다.

최근 자료를 찾지 못해 2016년 중반의 데이타베이스 점유율 자료에 따르면 MySQL이 69%로 압도적이 지위를 차지하고 있으며 다른 자료들과 비교해보면 MySQL의 점유율이 더욱 높아지는 추세를 보이고 있습니다.
반면 MariaDB등 다른 데이타베이스 점유율은 점점 낮아지는 추세를 보이고 있구요.

▽ 데이타베이스 시장점유율 Database market share 2016 2Q~3Q

데이타베이스 시장점유율 Database market share 2016 2Q~3Q

위 그래프에서 두번째로 높은 점유율을 가진 PostgreSQL은 일본 등에서 인기가 높은 데이타베이스라고 하네요.

세번째는 MySQL이 오라클로 넘어가면서 상업화가 짙어지고 이에 반발해 등장한 MariaDB가 10% 점유율로 그 뒤를 따르고 있습니다. MariaDB는 MySQL과 완벽하게 호환되면서 MySQL보다 가볍고 빠르며 라이센스가 비교적 자유롭기 때문에 소규모 사이트에서 선호를 보이고 있다고 합니다.

위키백과에 따르면 MariaDB는 MySQL과 아래처럼 호환된다고 합니다.

  • 데이터와 테이블 정의 파일(.frm) 파일이 바이너리 호환이 된다.
  • 모든 클라이언트 API, 프로토콜 그리고 구조가 동일하다.
  • 모든 파일이름과 바이너리, 경로, 포트, 소켓 그리고 기타 등등이 동일하다.
  • 모든 MySQL 커넥터(PHP, Perl, 파이썬, 자바, .NET, MyODBC, Ruby, MySQL C 코넥터 등)가 마리아 DB와 동일하게 작동한다.

현재는 MySQL과 MariaDB는 호환 되기 때문에 무엇을 선택해도 무방할 것 같습니다. 별 문제없이 마이그레이션 된다고 합니다.

저는 상대적으로 가볍고 빠르다는 말에 현혹되어 MariaDB를 선택했습니다 아마 본격적인 비지니스를 한다면 라이센스가 비싸지만 지원이 풍부한 MySQL을 선택할 수도 있겠습니다.

4.1.3. PHP 버젼 선택

새롭게 시작한다면 당연 PHP 최신 버젼인 PHP 7.2를 설치하는 게 맞겠죠.
다만 적용해야하는 플러그인들의 호환성을 고려한다면 5.x대를 선택할 수 도 있겠네요.

4.2. 서버 세팅 준비

이하에서는 위에서 결정한 내용을 토대로 서버 세팅을 살펴 보겠습니다.

더 구체적인 내용은 아래 포스팅을 참조하시기 바랍니다.

사이트 운영을 위한 안내 – 웹서버 세팅에서 워드프레스 설치까지(우분투 17.10, NGINX 1.13.6, Marian DB 10.2, PHP7.2)

4.2.1. 쉘 기본 언어값 확인

지금부터 작업은 터미널에서 작업 내용입니다.

먼저 시작하기 전에 현 운영체제의 프로그램을 최신으로 업데이트합니다.

# apt-get update
# apt-get upgrade -y

다음으로 쉘 기본 언어값 확인합니다. apache2 명령어를 쳐서 영어로만 나오면 그냥 넘어가고 중국어나 일본어 나온다면 영어로 바꾸어야 합니다.

# apache2
The program 'apache2' is currently not installed. You can install it by typicdng : 
apt install apache2-bin

위처럼 영어로 나오면 넘어가고 다른 언어가 나온다면 /etc/default/locale 의 파일 내용을 변경

# vi /etc/default/locale

에서 아래 내용을 반영합니다.

LANG="en_US.UTF-8"
LANGUAGE="en"

4.2.2 시스템 시간 설정

dpkg-reconfigure tzdata

GUI 환경에서 Asia를 선택하고 이어서 Seoul을 선택

서버 시간 세팅_Seoul

그러면 아래와 같은 결과를 출력합니다.

Current default time zone: 'Asia/Seoul'
Local time is now:      Sat Oct 14 16:24:42 KST 2017.
Universal Time is now:  Sat Oct 14 07:24:42 UTC 2017.

4.2.3 APT 소스 리스트 파일에 Nginx, PHP, MariaDB 저장소 추가

sources.list를 열어서 파일 맨 끝에 소스리스트를 추가

# vi /etc/apt/sources.list

파일 맨 끝에 아래 내용 추가

# Nginx
deb https://packages.nginx.org/unit/ubuntu/ artful unit
deb-src https://packages.nginx.org/unit/ubuntu/ artful unit

# MariaDB 10.2 repository list - created 2018-01-11 12:11 UTC
# http://downloads.mariadb.org/mariadb/repositories/
deb [arch=amd64,i386] http://ftp.kaist.ac.kr/mariadb/repo/10.2/ubuntu artful main
deb-src http://ftp.kaist.ac.kr/mariadb/repo/10.2/ubuntu artful main

4.2.4. 각 저장소 보안키 다운로드 후 시스템에 등록

nginx 보안키 다운로드 후 적용합니다.

cd /root
wget http://nginx.org/keys/nginx_signing.key
apt-key add nginx_signing.key
rm nginx_signing.key

다음으로는 MariaDB 보안키 다운로드 후 적용.

apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8

다음으로는 PHP 저장소 추가 및 보안키 등록

# apt-get install software-properties-common
# add-apt-repository ppa:ondrej/php

add-apt-repository ppa:ondrej/php를 실행하면 여기서 아래와 같은 메세지가 나오면서 엔터를 치라는 메세지가 나오는데요. 고민하지말고 엔터를 치면됩니다.

Co-installable PHP versions: PHP 5.6, PHP 7.x and most requested extensions are included.

You can get more information about the packages at https://deb.sury.org

BUGS&FEATURES: This PPA now has a issue tracker:
https://deb.sury.org/#bug-reporting

CAVEATS:
1. If you are using php-gearman, you need to add ppa:ondrej/pkg-gearman
2. If you are using apache2, you are advised to add ppa:ondrej/apache2
3. If you are using nginx, you are advise to add ppa:ondrej/nginx-mainline
   or ppa:ondrej/nginx

PLEASE READ: If you like my work and want to give me a little motivation, please consider donating regularly: https://donate.sury.org/

WARNING: add-apt-repository is broken with non-UTF-8 locales, see 
https://github.com/oerdnj/deb.sury.org/issues/56 for workaround:

# LC_ALL=C.UTF-8 add-apt-repository ppa:ondrej/php
 More info: https://launchpad.net/~ondrej/+archive/ubuntu/php
Press [ENTER] to continue or ctrl-c to cancel adding it

여기서 엔터를 눌러주면 된다..

지금까지 작업한 APT 패키지 정보를 업데이트 합니다.

# apt-get update

4.3. Nginx 설치

Nginx를 설치하고 nginx를 다시 가동(restart)시킵니다.

# apt-get install nginx

# service nginx restart
# nginx -v  // Version check

4.4. PHP 7.2 설치

PHP7-FPM 최신버전인 PHP7.2를 설치합니다. 2018년 1월 20일 현재 최신 버젼은 PHP7.2.1이네요.

PHP 최신 다운로드 버젼 확인 하러 가기

# apt-get install php7.2

PHP7,2을 설치하고 나서 관련 모듈을 설치합니다. 이 과정에서 일반적으로 널리 사용되는 모듈 list가 많이 돌아다니고 있으므로 이를 기준으로 설치해도 되고, 아니면 PHP7,2 모듈 패키지 리스트를 보고 선택을 다시 할 수도 있습니다.

# apt-get install php7.2 php7.2-fpm php7.2-cli php7.2-common php7.2-json php7.2-opcache php7.2-mysql php7.2-mbstring php7.2-mcrypt php7.2-zip php7.2-fpm  php7.2-gd php7.2-curl php7.2-xml php7.2-mcrypt php7.2-readline

php.ini 파일 수정

파일 수정은 fpm과 cli 폴더의 php.ini를 모두 수정해 주어야 합니다. fpm을 우선적으로 수정

  • date.timezone을 찾아 Asia/Seoul로 변경
  • cgi.fix_pathinfo=0 값으로 변경
  • 쿠키값 보안을 위해서 session.cookie_httponly 와 session.cookie_secure 값을 1을 준다.
# vi /etc/php/7.2/fpm/php.ini
# vi /etc/php/7.2/cli/php.ini

PHP 기본 세팅의 변경,

아래는 PHP 기본 세팅을 변경하는 명령어입니다. 아래 명령을 보듯이 fpm 폴더에 있는 php.ini 파일이 변경됩니다.

sed -i "s/memory_limit = .*/memory_limit = 256M/" /etc/php/7.2/fpm/php.ini
sed -i "s/upload_max_filesize = .*/upload_max_filesize = 1024M/" /etc/php/7.2/fpm/php.ini
sed -i "s/zlib.output_compression = .*/zlib.output_compression = on/" /etc/php/7.2/fpm/php.ini
sed -i "s/max_execution_time = .*/max_execution_time = 18000/" /etc/php/7.2/fpm/php.ini

php.ini 파일 수정이 끝나면 PHP-FPM service를 다시 시작합니다.

# systemctl restart php7.2-fpm.service

4.5. MariaDB 설치

안정화된 MariaDB는 버젼 10.2입니다. (2018년 1월 20일)

MariaDB Downloads, Setting up MariaDB Repositories

4.5.1. 업데이트 및 MariaDB 설치

앞에서 저장소와 키를 등록했으므로 간단하게 아래 명령으로 MariaDB를 설치할 수 있습니다.

# apt-get update
# apt-get -y install mariadb-server

설치 도중에 New password를 설정하는 화면이 나옵니다. 설치가 완료된 후 아래 명령어로 서비스 상태를 확인할 수 있습니다.

# service mysql status

4.5.2. PHP-FPM에 DB 연동관련 모듈설치

# apt-get install php7.2-mysql

4.5.3. 기본 언어셋 설정

이는 매우 중요한 세팅으로 반드시 필요합니다.

# vi /etc/mysql/conf.d/mariadb.cnf

아래 내용으로 변경.

# MariaDB-specific config file.
# Read by /etc/mysql/my.cnf

[client]
# Default is Latin1, if you need UTF-8 set this (also in server section)
default-character-set = utf8mb4

[mysqld]
#
# * Character sets
#
# Default is Latin1, if you need UTF-8 set all this (also in client section)
#
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
character_set_server = utf8mb4
collation_server = utf8mb4_unicode_ci

변경 내용을 반영해 DB를 다시 시작합니다.

service mysql restart

4.6 Nginx 와 PHP-FPM 연결

nginx는 기본적으로 nginx 사용자 권한으로 실행되고, PHP-FPM 프로그램은 기본적으로 www-data 사용자 권한으로 실행되므로 둘의 사용자 권한을 www-data로 일치시킵니다.

vi /etc/nginx/nginx.conf
  • user nginx; 를 user www-data; 로 변경
  • worker_processes 1; 를 worker_processes auto; 로 바꾼다. 고사양 서버에서 성능이 더 좋아진다고. 일반적으로 트래픽이 적은면 1을 사용하고 트래픽이 많아지면 auto를 사용한다.
service nginx restart
vi /etc/nginx/conf.d/default.conf
fastcgi_params 내용 수정

fastcgi_params를 열어서 아래 내용으로 변경합니다.

vi /etc/nginx/fastcgi_params

아래와 같이 변경

fastcgi_param   QUERY_STRING            $query_string;
fastcgi_param   REQUEST_METHOD          $request_method;
fastcgi_param   CONTENT_TYPE            $content_type;
fastcgi_param   CONTENT_LENGTH          $content_length;

fastcgi_param   SCRIPT_FILENAME         $document_root$fastcgi_script_name;
fastcgi_param   SCRIPT_NAME             $fastcgi_script_name;
fastcgi_param   PATH_INFO               $fastcgi_path_info;
fastcgi_param   PATH_TRANSLATED         $document_root$fastcgi_path_info;
fastcgi_param   REQUEST_URI             $request_uri;
fastcgi_param   DOCUMENT_URI            $document_uri;
fastcgi_param   DOCUMENT_ROOT           $document_root;
fastcgi_param   SERVER_PROTOCOL         $server_protocol;

fastcgi_param   GATEWAY_INTERFACE       CGI/1.1;
fastcgi_param   SERVER_SOFTWARE         nginx/$nginx_version;

fastcgi_param   REMOTE_ADDR             $remote_addr;
fastcgi_param   REMOTE_PORT             $remote_port;
fastcgi_param   SERVER_ADDR             $server_addr;
fastcgi_param   SERVER_PORT             $server_port;
fastcgi_param   SERVER_NAME             $server_name;

fastcgi_param   HTTPS                   $https;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param   REDIRECT_STATUS         200;

5. 웹서버 보안 세팅

웹서버 보안에 대해서는 아래 포스팅을 참조하세요.

가상서버호스팅에서 서버 보안 설정 방법 – Nginx +Ubuntu 16.04의 경우

랜섬웨어 대응, 서버 및 워드프레스 필수 보안 설정 15가지

5.1. Ubuntu 방화벽 – ufw 설정

방화벽을 세팅해 최소한의 포트만 열어 놓습니다.

  • 일반 및 SSL 설치 시 작동 가능토록 80, 443포트는 열어둔다.
  • ssh에서 널리 알려진 22포트는 해킹의 집중 대상이 되므로 자신많이 알수 있는 포트를 바꾼다. 이 작업은 sshd_config에서 사용할 포트를 지정해야 한다.
  • /etc/ssh/sshd_config 에서 Port 22 를 찾아서 자기가 사용할 포트 숫자를 기억하기 쉽고 10000자리이상에서 임의의 숫자를선택한다. 예를 들어 58722, 65322 등등
ufw enable  # 방화벽을 활성화한다.
ufw allow 80/tcp  # 일반 웹 정보 관련 입출력 통로
ufw allow 443/tcp  # SSL 설치 시 웹정보 관련 입출력 통로 
ufw allow ****/tcp  # ssh를 위한 포트, 뒤에서 설명하겠지만 22번 포트는 너무 알려져 있어 여기로 공격하는 경우가 많아 포트를 바꾼다.

5.2. Fail2ban을 설치하여 보안을 강화

로그를 분석해 의심스러운 접근을 금지시키는 방법이 DenyHosts나 Fail2Ban이라는 프로그램입니다.

이 중 Fail2ban은 DenyHosts보다 훨씬 진보된 방식으로 SSH, Apache, Courier, FTP 등등에서 의심스러운 접근을 차단할 수 있는 프로그램으로 Fail2ba은 로그 파일을 모니터링해서 넘 많은 패스워드 입력 실패나 공격 감행 징후들이 보이면 IP를 차단합니다.

먼저 Fail2Ban을 설치해보죠.

apt-get install fail2ban

그 다음 설정을 변경. 이는 jail.conf 파일을 수정해야 합니다.

vi /etc/fail2ban/jail.conf

여기에서 ignoreip, bantime, findtime , maxretry 등을 수정합니다.

  • ignoreip에는 ban을 하면 않되는 IP를 적는다. 10.100.102.103/32 형식으로 적으며, 추가는 스페이스바로 구분한다.
  • bantime은 접속 차단 시간으로 기본이 600(10분)으로 되어 있음
  • findtime은 통계를 찾을 시간.
  • maxretry 는 fail 횟수이다. 기본으로 5가 세팅되어 있는데 이 정도면 충분하다고 보고 유지했다.

5.3. ssh 포트 변경

일반적으로 ssh포트로 22번을 사용하는데 이는 너무 알려진 포트이므로 이를 이용해 공격해오는 경우가 있습니다. 따라서 자기만아는 포트 번호로 변경 사용하는 게 필요합니다.

이를 위해서는 먼저 sshd_config에서 22번대신 사용할 포트 번호로 바꿉니다. 즉 /etc/ssh/sshd_config 에서 Port 22 를 찾아서 자기가 사용할 포트 숫자를 기억하기 쉽고 10000자리이상에서 임의의 숫자로 변경합니다. 예를 들어 58722, 65322 등등

이렇게 포트를 변경한 후 ssh 서비스를 재시작 합니다. 그리고 기존 ssh port로 사용했던 22번 포트는 접속할 수 없도록 막아줍니다.

ufw enable  # 방화벽을 활성화한다.
ufw allow 80/tcp  # 일반 웹 정보 관련 입출력 통로
ufw allow 443/tcp  # SSL 설치 시 웹정보 관련 입출력 통로 
ufw allow ****/tcp  # ssh를 위한 포트, 22번 포트는 너무 알려져 있어 여기로 공격하는 경우가 많아 포트를 바꾼다.
ufw deny 22/tcp  # ssh용으로 22포트를 사용할 수 없게 한다.

5.4. ping 금지

해킹 목적으로 네트워크 침입을 시도 시 핑(Ping)을 통해 특정 서버가 살아있는지 확인하는 경우가 많고, 고전적이긴 하지만 DDOS 공격 시 무한 핑(ping) 요청으로 서버를 무력화를 시도하는 경우도 있기때문에 핑(ping)을 허용하지 않는 게 좋습니다.

이를 위해서는 방화벽 정책을 변경해 줍니다. 변경해야하는 설정 파일은 아래 경로를 참조

/etc/ufw/before.rules

아래 명령에서 ACCEPT를 DROP으로 변경하거나 삭제해 준다.

  -A ufw-before-input -p icmp --icmp-type destination-unreachable -j ACCEPT  → DROP으로 변경
  -A ufw-before-input -p icmp --icmp-type source-quench -j ACCEPT   → DROP으로 변경
  -A ufw-before-input -p icmp --icmp-type time-exceeded -j ACCEPT   → DROP으로 변경
  -A ufw-before-input -p icmp --icmp-type parameter-problem -j ACCEPT   → DROP으로 변경
  -A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT   → DROP으로 변경

5.5. 보안 강화 HTTP 헤더 사용

HTTP 헤더에 보안을 강화하기 위한 여러 헤더를 적용합니다.

  • X-Frame-Options : 클릭 하이재킹을 방지하기 위한 헤더로 deny로 설정하면 iframe 에서 렌더링을 하지 않습니다. sameorigin 은 origin이 일치하지 않을 경우 렌더링을 하지 않습니다.
  • X-Content-Type-Options: “nosniff” 만 설정할 수 있으며 잘못된 MIME 형식이 포함된 응답을 거부.aspx)합니다.
  • X-XSS-Protection: IE와 Chrome 브라우저가 지원하며 특정 유형의 XSS(cross site script)공격.aspx)을 차단해 줍니다.
nginx 설정
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
apache 설정
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff
Header set X-XSS-Protection "1; mode=block"

### 5.6. 서버의 중요 파일 접근 차단

웹서버에서 URL Re-writing 을 처리하거나 주요 옵션을 성정한 \ .htaccess 나 워드프레서 설정값을 보광하고 있는 wp-config.php, git 그리고 subversion의 형상 관리 메타 정보(.git, .svn), 설정 파일(.inc, .ini, .cfg, .conf) 같은 매우 중요요 파일들이 있습니다.

해커가 이런 파일을 내려 받아 서버의 정보를 파악할 수 있으므로 이런 파일에 대한 접근을 차단 합니다.

#### nginx 설정

~~~javascript
location ~ /\.(ht|git|svn) {
    deny all;
}
location ~ /wp-conf* {
    deny all;
}
location ~ /.*\.(inc|ini|conf|cfg)$ {
    deny all;
}

6. Let’s Encrypt 무료 SSL인증서 발급

보안의 일종으로 Let’s Encrypt 무료 SSL인증서 발급해 보겠습니다. 이 글은 주로 아래 글을 참조하였습니다.

[워드프레스 Tips] Let’s Encrypt 무료 SSL인증서 발급 및 자동 갱신 방법

[워드프레스 Tips] Lets’ Encrypt SSL 인증서 수동 갱신 방법

서버를 세팅하다보면 본의아니게 서버 설치를 반복하게 되는데요. 이러다보면 et’s Encrypt SSL인증서도 여러번 설치하게 됩니다.
그런데 Let’s Encrypt SSL인증서는 1주일에 5번까지 발급 받을 수 있기 때문에 이점은 유의할 필요가 있습니다.

5번이 넘어서면 아래와 같은 메세지가 나오면서 발급이 안됩니다.

  • An unexpected error occurred: There were too many requests of a given type :: Error creating new cert :: too many certificates already issued for exact set of domains: test.com www.test.com

6.1. git 설치하고 certbot설치 하기

첫째 /root에서 작업을 진행할 수 있게 /root로 이동

둘째, 필요한 소프트웨어를 GitLab에서 받을 수 있도록 git를 설치

처음 소프트웨어 설치 시 관련 소프트웨어를 업데이트할 수 있도록 Git repositories를 등록해 놓았다면 별도로 설치할 필요는 없습니다.

셋째, 새로운 작업을 시작하기전에 항시 최신 소프트웨어가 없는지 점검하기 위해서 업데이트 명령.

넷째, git 설치 명령.

다섯째, git이 설치되면 git 저장소에서 SSL 인증을 위한 소프트웨어 클라이언트인 certbot를 다운.

cd /root   # /root 디렉토리로 이동해 작업 시작
apt-get update   # 항상 소프트웨어를 설치하기 전에 최신 업데이트가 있는 지 학인
apt-get install git # git 설치
git clone https://github.com/certbot/certbot  # certbot 설치

6.2. certbot으로 인증서를 생성

첫째, certbot이 깔린 폴더로 이동. cd certbot 명령 사용

둘째, nginx를 중단. Let’s Encrypt 의 인증 방식인 Standalone plugin 은 서버 인증을 위해서 80포트를 이용하는데 nginx가 80 포트를 계속 사용하고 있으면 인증이 제대로 될 수 없으므로 nginx 서버를 일시적으로 멈추는 것.

셋째, 인증 절차에 돌입. 여기서 certonly 명령을 사용. certonly는 인증서만 설치하겠다는 명령으로 nginx에선 아직 아파치처럼 다양한 명령 옵션이 없음.

넷째, 나오는 화면 요구사항에 맞추어 인증을 진행.

cd certbot  # /certbot 디렉토리로 이동해 작업 시작
service nginx stop   # 80포트를 사용하지 않토록 nginx를 중단시킴
./certbot-auto certonly # 인증 절차 진행, 조금 시간이 걸립니다.
service nginx start # 작업이 끝나면 다시 nginx를 가동시킴

인증시 이메일주소를 입력 후 적용하고 싶은 사이트 주소를 입력하게 끔 되어 있는데 큰 어려움은 없이 진행된다.

6.3. DH Param 생성, 적용하기

앞의 작업으로 인증서 설치는 끝나지만 보다 보안을 강화하기 위해서 DH Param 생성 한다.

DH Param은 일부 암호화 알고리듬에 사용되는 커다란 난수 하나를 미리 생성해 두어서 암호화 성능을 향상시키고 보안을 높이는 방법이다.

mkdir /etc/nginx/ssl
cd /etc/nginx/ssl
openssl dhparam -out dhparams.pem 4096  # 2048비트로 하려면 4096대신 2048로 대체 한다.
openssl rand 48 > session_ticket.key  # 세션 티켓키도 생성 이는 시간이 거의 걸리지 않는다.

7.3. 암호화 알고리즘 설정하기

인증서를 획득하는게 중요한게 아니고 얼마나 철저한 암호화 설정을 하느냐가 중요하기에 암호화 알고리즘을 적용한다.

아래는 nginx 설정 파일 sever 블럭안에 넣는 암호화 알고리즘입니다.

# Letsencrypt 기본 RSA 인증서
    ssl_certificate /etc/letsencrypt/live/happist.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/happist.com/privkey.pem;

    #OCSP Stapling(인증서가 유효하다는 증명을 미리 받아두어서 사이트에 처음 방문할 때 접속 속도를 높여주는 방법dla)
    ssl_trusted_certificate /etc/letsencrypt/live/happist.com/chain.pem; 
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4  valid=300s;
    resolver_timeout 10s;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;

    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

    ssl_session_timeout 5m;
    ssl_session_cache shared:SSL:50m;

    ssl_dhparam /etc/nginx/ssl/dhparams.pem;
    ssl_session_tickets        on;
    ssl_session_ticket_key /etc/nginx/ssl/session_ticket.key;

   # HTST 설정 ; 해당 도메인에 접근시 HTTPS로 접속을 강제하는 옵션 
    # 밑 옵션을 넣은 후 https://hstspreload.appspot.com  사이트에서 도메인 등록 필요
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";

    #HPKP 설정
    #add_header Public-Key-Pins 'pin-sha256="lrJxl2mZhg9wlQ9JncdCBWyMq9oInWn2Wecefuv61T4=" ; pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=" ; pin-sha256="Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys=" ; max-age=2592000; includeSubDomains';

8. 워드프레스 설치

이제 워드프레스를 설치합니다. 아래 내용은 아래 포스팅을 참조하여 일정 부분 수정한 것입니다.

[워드프레스 Tips] 가상서버호스팅(VPS)에서 워드프레스 설치하기

8.1. 가상호스트 루트 폴더(document root) 정하기

기본으로 우분투 16.04의 기본 디렉토리는 /usr/share/nginx/html/ 입니다. 사람들의 취향에 따라서 다양한 위치에서 설치하고자하는 욕구가 있으나 보안이나 원인을 알수 없는 문제가 지속 발생하므로 가능하면 /usr/share/nginx/html/ 를 그냥 사용하는 게 좋다.

vultr에서 서버를 세팅하면 몇가지 우분투의 기본 위치는 아래와 같습니다.

  • 기본 루트 폴더(document root) 디렉토리는 /usr/share/nginx/html/
  • nginx 설정 파일 위치는 /etc/nginx/conf.d

8.2. 디렉토리 소유권 변경

다음으로는 기본 디렉토리의 소유권을 nginx 기본 사용자인 www-data에게 넘긴다.

# chown -R www-data:www-data /usr/share/nginx/html/

8.3. 파일 권한 설정(필요 시)

위의 디렉토리 소유권 변경이 제대로 되었다면 파일 권한 설정이 필요없습니다. 권한 설정은 제대로 작동되지 않을때 강제로 파일 권한을 준다고 생각하고 권한을 강제 조정합니다.

파일 권한을 확인해서 파일 권한을 755로 변경합니다.

# chmod -R 755 /usr/share/nginx/html

워드프레스 관련 디렉토리 소유권을 nginx인 www-data로 넘겼지만 가끔 플러그인들이 제대로 설치가 안되는 경우도 나타납니다. 이럴경우 파일 권한을 더 정확히 줍니다. 아래 폴더들은 디렉토리에 파일을 써야하므로(설치) 일정 권한이 필요합니다.

  • wordpress 폴더
  • wp-content/
  • wp-content/plugins/
  • wp-content/uploads
  • wp-content/upgrade/ (워드프레스 코어 업그레이드 필요)

이러한 폴더들에 대해서는 파일 권한을 확인해서 파일 권한을 755로 변경한다.

chmod 755 /usr/share/nginx/html/
chmod 755 /usr/share/nginx/html/wp-content/
chmod 755 /usr/share/nginx/html/wp-content/themes/
chmod 755 /usr/share/nginx/html/wp-content/plugins/
chmod 755 /usr/share/nginx/html/wp-content/uploads/
chmod 755 /usr/share/nginx/html/wp-content/upgrade/

이렇게 선별적으로 권한 변경을 하는게 조금 더 안정적일 수 있는데 귀찮다면 -R옵션을 사용해 일괄 변경하는 방법도 있습니다.

8.4. Nginx 가상호스트 설정 파일을 생성, 작성

이 단계이후 할일은 Nginx 가상호스트 설정 파일에 이 새로 만든 document root 위치를 반영 시켜주는 것이죠.

이 설정은 우분투 버젼 17.10기준 /etc/nginx/conf.d라는 폴더에 있는 default 파일에서 수정 가능합니다. 이렇게 할수도 있지만 멀티 사이트를 운영할 시 설정 파일이 너무 복잡해져서 혼란스럽지않게 사이트마다 별도 파일로 관리를 할 수 있습니다.

변경하기 전 default.conf 파일을 처음 열어보면 아래와 같은 내용을 볼 수 있는데 이 내용을 변경해서 각 사이트명+conf를 만들어 내용을 채워 넣습니다.

각 도메일별 서버블록 파일을 만들어 /etc/nginx/conf.d에 올립니다.

아래는 본인이 사용했던 설정이다.

server {
    listen       80;
    server_name test1.com www.test1.com;
    return       301 https://$server_name$request_uri;
    }

server {
    listen       443 ssl http2;
    server_name  test1.com www.test1.com;
    root   /usr/share/nginx/test1.com;

    #set same size as post_max_size(php.ini or php_admin_value).
    client_max_body_size 1024M;

    server_tokens off; # 버전 숨기기 활성화

    add_header X-Frame-Options SAMEORIGIN;
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";

    charset utf-8;

    ssl_certificate /etc/letsencrypt/live/test1.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/test1.com/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/test1.com/chain.pem; 

    ssl_dhparam /etc/nginx/ssl/dhparams.pem;

    # Enable HSTS. This forces SSL on clients that respect it, most modern browsers. The includeSubDomains flag is optional.
    add_header Strict-Transport-Security "max-age=31536000";

    # Set caches, protocols, and accepted ciphers. This config will merit an A+ SSL Labs score.
    #ssl_session_cache shared:SSL:20m;
    ssl_session_timeout 10m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_ciphers 'ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5';


    access_log /var/log/nginx/test1.com.access.log;
    error_log /var/log/nginx/test1.com.error.log warn;

    location / {
       try_files $uri $uri/ /index.php?$args;
       index index.php index.html index.htm;
    }

    location ~ /(\.|wp-config.php|readme.html|license.txt|wp-comments-post.php) { 
       deny all;
    }

    location ~ /\.(ht|git|svn) {
        deny all;
    }

    location ~ /.*\.(inc|ini|conf|cfg)$ {
        deny all;
    }

    #Block scripts from being run that shouldn’t be running
    location ~* .(pl|cgi|py|sh|lua)$ {
        return 444;
    }

    location = /favicon.ico {
        log_not_found off;
        access_log off;
    }

    location = /robots.txt {
        allow all;
        log_not_found off;
        access_log off;
    }

    #the site that should not be public
    location ~* wp-admin/includes { deny all; }
    location ~* wp-includes/theme-compat/ { deny all; }
    location ~* wp-includes/js/tinymce/langs/.*\.php { deny all; }
    location /wp-content/ { internal; }
    location /wp-includes/ { internal; }

    # Letsencrypt의 Webroot Plugin을 사용하기 위해서 임
    location ~ /.well-known {
    allow all;
    }

    location @wp_admin_ban {
    rewrite ^(.*) http://test1.com permanent;
    }

    # Add trailing slash to */wp-admin requests.
    rewrite /wp-admin$ $scheme://$host$uri/ permanent;

    # Aggressive caching for static files that rarely/never change
    location ~* \.(asf|asx|wax|wmv|wmx|avi|bmp|class|divx|doc|docx|eot|exe|gif|gz|gzip|ico|jpg|jpeg|jpe|mdb|mid|midi|mov|qt|mp3|m4a|mp4|m4v|mpeg|mpg|mpe|mpp|odb|odc|odf|odg|odp|ods|odt|ogg|ogv|otf|pdf|png|pot|pps|ppt|pptx|ra|ram|svg|svgz|swf|tar|t?gz|tif|tiff|ttf|wav|webm|wma|woff|wri|xla|xls|xlsx|xlt|xlw|zip)$ {
    expires 31536000s;
    add_header Pragma public;
    add_header Cache-Control "max-age=31536000, public";
    }

    location ~* \.(css|js)$ {
    expires 86400s; 
    access_log off;
    add_header Pragma public;
    add_header Cache-Control "max-age=86400, public";
    }

    # Add PHP handler
    location ~ [^/]\.php(/|$) {
        fastcgi_split_path_info ^(.+?\.php)(/.*)$;
        if (!-f $document_root$fastcgi_script_name) {
            return 404;
        }

        fastcgi_pass unix:/run/php/php7.2-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param   SCRIPT_NAME        $fastcgi_script_name;

        fastcgi_buffer_size 128k;
        fastcgi_buffers 256 16k;
        fastcgi_busy_buffers_size 256k;
        fastcgi_temp_file_write_size 256k;

        # This file is present on Debian systems..
        include fastcgi_params;

    }

    # Ensure requests for pagespeed optimized resources go to the pagespeed handler
    # and no extraneous headers get set.
    location ~ "\.pagespeed\.([a-z]\.)?[a-z]{2}\.[^.]{10}\.[^.]+" {
    add_header "" "";
    }
    location ~ "^/pagespeed_static/" { }
    location ~ "^/ngx_pagespeed_beacon$" { }


}

권한부여하고 설정 파일에 반영이 끝나면 설정이 제대로 되었는지 테스트합니다. 테스트 명령어는 nginx -t

# nginx -t

테스트에서 아래와 같은 메세지가 나오면 성공

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

이렇게 성공하게 되면 nginx를 정식으로 다시 가동시킨다.

# systemctl restart nginx  또는 service nginx restart

8.5. 워드프레스 설치를 위한 DB 생성

우선 워드프레스가 사용할 DB 생성이 필요하다. 아래는 Maria DB에 접속해서 DB를 생성하는 과정을 간략히 정리한 것입니다.

MariaDB에 접속

mysql -u root -p

DB 생성

CREATE DATABASE wp;

DB사용자 계정 생성

CREATE USER user1@localhost;

사용자 계정 패스워드 설정

SET PASSWORD FOR user1@localhost= PASSWORD('password');

사용자가 wp라는 DB에 접근할 권한 부여.

GRANT ALL PRIVILEGES ON wp.* TO user1@localhost IDENTIFIED BY 'password';

설정값을 적용

FLUSH PRIVILEGES;

8.6. 워드프레스 파일 받아 설치하기

워드프레스 한국 버젼은 워드프레스의 공홈이라하 할 수 있는 https://ko.wordpress.org에서 다운 받을 수 있습니다.

워드프레스 최신 버젼을 릴리즈 하는 곳

여기에서 최신 버젼의 링크주소를 복사합니다.

cd /home/happist  # 설치할 디렉토리로 이동
wget https://ko.wordpress.org/wordpress-4.8.2-ko_KR.tar.gz  # 워드프레스 최신 버전의 링크주소
tar -xzf https://ko.wordpress.org/wordpress-4.8.2-ko_KR.tar.gz     # 압축을 푼다.

8.7. 워드프레스 설치

워드프레스 설치파일을 /home/사용자계정/www에 올려놓았다면 인터넷상에서 사이트 주소를 치면 바로 워드프레스 설치 화면으로 들어 갑니다. 여기까지왔다면 거의 성공한 것이나 마찬가지.

여기서부터는 그 유명한 5분 설치가 가능합니다. 기존에 준비했던 정보들을 입력하면서 진행하면 됩니다.

아래 설치 단계별 이미지를 순서대로 소개하니 이를 이를 참조하면 됩니다.

8.7.1. 워드프레스 설치 시작 – 워드프레스에 오신 것을 환영합니다

처음으로 나오는 화면

워드프레스 설치 시작 화면_워드프레스에 오신 것을 환영합니다.

8.7.2. 데이타베이스 연결 설정

위 장면에서 let’s go를 누르면 아래 화면이 나오죠.
여기에서 데이타베이스 연결을 위한 세팅합니다.

  • db name
  • db user
  • 비밀번호
  • 데이타베이스 호스트 대개 그냥 localhost를 사용한다.
  • 데이타베이스 접두어, wp를 대부분 사용하는 듯

워드프레스 설치 시작 화면_데이타베이스 연결 설정

8.7.3. 데이타베이스 설치과정 완료

데이타베이스 세팅이 완료되면 아래와 같이 설치 과정을 마쳤다는 메세지가 나옵니다.

워드프레스 설치 시작 화면_데이타베이스 설치과정 완료

8.7.4. 워드프레스 5분 설치과정에 오신 것을 환영합니다.

위에서 데이타베이스 설정이 끝나면 바로 본격적인 워드프레스 설치 과정이 시작됩니다. 이 단계가 너무 쉽고 간단하기때문에 워드프레스에서는 5분 워드프레스 설치 과정이라고 홍보하고 있죠.

여기에서는 관리자가 필요한 항목들을 입력하고 춰드프레스 설치하기를 누릅니다.

  • 사이트제목
  • 사용자명
  • 비밀번호
  • 이메일주소

워드프레스 설치 시작 화면_워드프레스 5분 설치과정에 오신 것을 환영합니다

8.7.5. 워드프레스 설치 완료

그러면 몇분 걸리지 않아 워드프레스가 설치되고 워드프레스 대시보드 화면이 나타납니다.

이제부터는 정상적으로 워드프레스로 사이트를 운영하면 됩니다.

워드프레스 설치성공 후 첫 시작 화면05

8.7.6. 워드프레스 세팅

워드프레스가 설치 되었으면 몇가지 세팅힙니다.

  • 먼저 고유주소를 세팅, SEO에 좋다고 누가 그래서 ID와 이름으로 고유주소를 만들었다. 이는 생각보다 기렁지고 한글 문제는 속을 썩힌다. – /%post_id%/%postname%/
  • 적절한 테마 설정
  • 테마에 따른 위젯 등 설정

아래는 워드프레스 최적화 관련 포스트인데 참조하시기 바랍니다.

워드프레스 최적화를 위한 18개월간의 고민, 그 노하우를 담다.

9. 웹서버 모니터링 또는 튜닝

이렇게 웹서버 세팅이 완료되어 본격적으로 사이트 운영이 시작되었다면 사이트가 잘 운영되는지, 효율적인지 볼 필요가 있을 것입니다.

그래서 웹서버 운영시 사용하는 몇가지 모니터링 프로그램을 소개해 봅니다.

9.1. Htop(Linux Process Monitoring)

Htop은 윈도우즈의 작업관리자와 비슷하게 리눅스에서 시스템 사용량 즉 CPU 사용량, 메모리 사용량 등을 어느 정도 비쥬얼적으로 모니터링할 수 있는 프로그램입니다.

리눅스에는 이러한 시스템 자원 상황을 모니터링하는 프로그램에는 Top, Htop, Atop, Nmom, Glances, Saider 등이 있는데요. 최근 Top을 개량한 Htop이 많이 호평을 받고 있습니다.

9.1.1. Htop 설치

Ubuntu에서는 apt-get 명령어를사용해 서버 모니터일 프로그램인 htop을 설치 합니다.

apt-get install htop

9.1.2. Htop의 사용

여기에서는 Htop의 사용법을 간략히 설명해 보겠습니다.
기본적으로 Htop은 터미널에서 htop를 쳐서 바로 사용 가능합니다. 너무 간단하죠.

htop

그러면 아래와 같은 화면을 보여줍니다.
Htop은 기본적으로 하나의 화면에서 모든 정보를 볼 수 있도록 되어 있으며, 상단에는 시스템의 주요 내용을 요약해 보여주고 있고, 그 아래에는 각 프로세스들의 각 활동 내용을 자세하게 보여줍니다.
이 모든 상황은 1초 단위로 업데이트 됩니다.

구체적으로 Htop 화면 상단 왼쪽에 CPU, Swap, Memory 사용량을 총량 비 사용량을 표시해 줍니다. 일CPU가 여러 개일 경우는 CPU 번호별로 사용율을 보여줍니다. 오른쪽에는 테스크 정보와 쓰레드 정보를 보여주고 있습니다.

또한 맨 하단에 각 기능별 단축키가 표시되어 있는데, Htop에서 F1 ~ F10까지 단축키에 각 기능들이 정의 되어 있습니다.

리눅스 시스템 모니터일 프로그램 htop 사용법

이에 대한 조금 더 자세한 내용은 아래 포스팅을 참조 바랍니다.

서버 모니터링 프로그램 Htop 사용 방법 – Ubuntu 기준

9.2. OPcache 모니터링

9.2.1. OPcache 의미와 설정법

OPcache는 byte코드로 컴파일된 명령문(PHP Script)으로 공유된 메모리에서 PHP 문서 해석 시간을 줄여 성능을 개선시키는 캐시 프로그램입니다. Opcache는 낮은 CPU 자원을 사용하면서 빠른 해석으로 개벌적 접속자가 상대적으로 빠른 속도감을 느낄 수 있습니다.

아래는 PHP Script를 처리하는 과정에 대한 플로우 차트인데 Cache와 PHP Script 컴파일이 잔행되는 프로세스를 살펴볼 수 있습니다. 이 플로우 차트는 Basics of PHP opcode cache 에서 가져왔습니다.

php opcache flow chart

Opcache는 PHP 5.5부터 내장되어 설치되며 5.4이하에서는 PECL 방식으로 사용이 가능하며 Opcache는 PHP.ini 파일에서 환경 설정을 효율적 세팅함으로써 효울을 더 높힐 수 있습니다.

9.2.2. OPcache 모니터링 프로그램 – Opcache-Status by Rasmus Lerdorf 설치

여러가지의 OPcache 모니터링 프로그램이 있지만 가장 간단한 OPcache-Status by Rasmus Lerdorf를 설치하고 모니터링하는 방법을 살펴 봅니다.

cd /var/www/example.com/  # 설치하고 싶은 디렉토리로 이동
wget https://raw.github.com/rlerdorf/opcache-status/master/opcache.php

설치 후 인터넷 브라우저에서 설치주소/opcache.php 명령으로 모니터링 프로그램을 볼 수 있습니다. 아래 이미지가 모니터링 프로그램으로 확인한 내용입니다.

OPcache 모니터링툴 작동 모습

이 모니터링 프로그램으로 OPcache가 제대로 작동하고 있는지 메모리 설정은 문제가 없는지 확인해 볼 수 있습니다. 저는 처음에 OPcache에 메모리를 256MB를 할당했다가 모니터링을 계속해보니 60~ 70MB 정도를 사용하는 것을 보고 메모리 할당량을 96MB로 낮추었습니다.

OPcache에 대한 전반적인 내용은 아래 포스팅을 참조 바랍니다.

[워드프레스 최적화] OPcache를 활용한 워드프레스 속도 최적화 방안

9.3. Memcached 모니터링 프로그램

이번에는 데이타베이스 Query 캐시로 많이 사용되는 Memcached 및 이를 모니터링하는 프로그램에 대해서 살펴보도록 하겠습니다.

9.3.1. Nginx서버에서의 Cache 종류

위애서 Opcache를 설명했지만 Nginx서버에서의 Cache는 크게 아래와 같이 정리될 수 있습니다.

  • Cache에는 Full page cache, PHP Script 결과를 모아 두는 cache, 데이타베이스 Query 결과를 모아두는 cache로 나눌 수 있습니다.
    NGINX 서버 작동 플로우차트 Flow chart
    • Full page cache는 PHP를 통해서 HTML 형태로 page를 구성한 결과를 보관했다가 요청이 오면 바로 보여주어 속도를 높이는 기법으로 Nginx에서는 FastCGI가 가장 좋은 성과를 보여 준다,
  • PHP Script Cache는 말 그대로 PHP Script를 컴파일한 결과를 공유 메모리에 저장하고 있다가 필요 시 사용하는 cache로 요즘 OPcache가 가장 성능이 좋다고 알려 있다.
  • OPcache와 Memcached의 차이는 OPcache는 위에서 설명한 대로 PHP Script 결과를 모아 두는 cache이고, Memcached는 주로 데이타베이스 쿼리(query) 결과를 보관하는 cfache라는 차이가 있다.

9.3.2. Memcached 모니터링 프로그램

Memcached 모니터링 프로그램으로는 PHPMemcachedAdmin 1.3.0을 활용해서 상황을 살펴 봅니다.

PHPMemcachedAdmin 1.3.0은 PHPMEMCACHEDADMIN : DOWNLOAD : VERSION 1.3.0에서 다운 받을 수 있습니다.

아래와 같은 방법으로 설치합니다.

cd /var/www/example.com/   # 설치 디렉토리로 이동

wget https://github.com/elijaa/phpmemcachedadmin/archive/1.3.0.tar.gz
tar -xvzf 1.3.0.tar.gz
cd phpmemcachedadmin-1.3.0
chmod +r *
chmod 0777 Config/Memcache.php

Memcached 모니터링 프로그램 phpmemcachedadmin-1-3-0

이 모니터링 프로그램을 사용하다보면 사이트의 데이타베이스에 비해서 지나치게 큰 Memcached 메모리를 할당하는 경우 hit율이 많이 떨어짐을 볼 수 있습니다. 이를 기반으로 적절한 Memcached 메모리를 정할 수 있을 것 같습니다.

Memcached 사용에 대해서는 아래 포스팅을 참조 바랍니다.

[워드프레스 최적화] 워드프레스에서 Memcached 이용해보기 – Ubuntu 16.04 + Nginx + PHP 7

10. 데이타베이스 튜닝

운영하는 사이트의 성능을 충분히 개선시키려면 데이타베이스 튜닝이 이루어져야 합니다. 이 부분은 어느 정도 난이도가 있습니다. 그렇지만 데이타베이스 튜닝을 도와주는 툴들이 많이 있고, 이 툴들의 도움을 받아 조금씩 성능을 개선해 볼 수 있습니다.

10.1. 데이타베이스 진단툴 MySQLTuner

데이타베이스 진단툴로 널리 쓰이고 있는 MySQLTuner 활용 방안을 살펴봅니다. 사실 전문가는 아니므로 어느 정도 서버가 가진 물리적인 성능을 제대로 활용할 수 있는 수준 정도로 개선방법을 찾는데 만족해야 할 듯 싶구요. 그 이상을 원한다면 전문가를 찾는 게 좋을 듯 합니다.

10.1.1. MySQLTuner 설치

MySQLTuner 설치는 아래와 같이 진행하면 됩니다. 당연히 터미널에서 아래 명령어를 사용해 설치할 수 있습니다.

wget http://mysqltuner.pl/ -O mysqltuner.pl
wget https://raw.githubusercontent.com/major/MySQLTuner-perl/master/basic_passwords.txt -O basic_passwords.txt
wget https://raw.githubusercontent.com/major/MySQLTuner-perl/master/vulnerabilities.csv -O vulnerabilities.csv
perl mysqltuner.pl

10.1.2. MySQLTuner 사용 명령어

MySQLTuner가 설치되었으면 터미널에서 적절한 명령어를 사용해 점검해 볼 수 있습니다. MySQLTuner 명령어에는 최소한도의 검토를 진행하는 명령어에서부터 굉장히 복잡한 분석을 하라는 명령까지 다양합니다.

  • perl mysqltuner.pl 가장 최소한의 점검 명령
  • perl mysqltuner.pl —buffers —dbstat —idxstat —sysstat —pfstat 디버깅없이 MySQL/MariDB의 대부분을 점검하라는 명령, 너무 길어서 그냥 눈앞에서 획획 지나가 버려서 이를 파일로 저장하라는 명령이 필요하다.
  • perl mysqltuner.pl —outputfile /tmp/result_mysqltuner.txt 최소 점검 결과를 파일로 저장
  • perl mysqltuner.pl —buffers —dbstat —idxstat —sysstat —pfstat —outputfile /tmp/result_mysqltuner.txt 최대 점검 결과를 파일로 저장
  • perl mysqltuner.pl —debug 디버깅 정보를 보여줌

보다 자세한 설명은 아래 포스팅을 참조 바랍니다.

[워드프레스 최적화] MySQLTuner로 빠른 워드프레스 데이타베이스 튜닝하기

10.2. MySQL 데이터베이스 오류 복구 및 최적화 툴 mysqlcheck

MySQL에서 자동으로 설치되는 mysqlcheck에서는 테이블이 손상 되었는지(check table), 손상된 테이블로 판면되면 자동으로 복구(repair table), 테이블 최적화(optimize table)해 속도를 개선하는 기능을 제공합니다.

mysqlcheck은 오직 서버가 구동되어 MySQL(또는 MariaDB) 데이타베이스가 작동되는 동안만 점검할 수 있습니다. 이와 유사한 기능을 하는 myisamchk은 서버가 작동하지 않는 동안에도 점검을 할 수 있다고 합니다.

10.2.1. mysqlcheck 명령어

mysqlcheck에서 사용 가능한 명령어는 아래와 같습니다.

명령어 수행 내용
-c, —check Check table for errors.
-a, —analyze Analyze given tables..
-o —optimize Optimize the tables.
-r, —repair Perform a repair that can fix almost anything except unique keys that are not unique.
—auto-repair If a checked table is corrupted, automatically fix it. Repairing will be done after all tables have been checked.
-A, —all-databases Check all the databases. This is the same as –databases with all databases selected.
-B, —databases Process all tables in the named databases. With this option, all name arguments are regarded as database names, not as table names.
—tables Overrides the –databases or -B option such that all name arguments following the option are regarded as table names.
-g, —check-upgrade Check tables for version-dependent changes. May be used with –auto-repair to correct tables requiring version-dependent updates.

10.2.2. 데이타베이스 테이블 오류 체크 및 자동 복구

여러가지 이유로 데이타베이스 테이블이 손상될 수 있습니다. 이때 mysqlcheck로 테이블 손상 복구를 시도해 볼 수 있습니다.

이 때 사용하는 명령어는 아래와 같습니다.

mysqlcheck -u [DB계정] -p[패스워드] --auto-repair [DB명]

만약 데이타베이스 전체를 검사하고 싶다면 아래 명령어를 사용합니다.

mysqlcheck -u [DB계정] -p[패스워드] --auto-repair --all-databases

보다 자세한 내용을 아래 포스팅을 참조하시기 바랍니다.

[워드프레스 최적화] 효율적인 MySQL 데이타베이스 최적화 및 복구 방법, mysqlcheck

11. 안전하고 효율적인 백업에 대해서

사이트를 운영하다보면 언제 무슨일이 일어날지 모릅니다. 그래서 항상 백업이 필요한데요. 여기에서는 어떻게 백업 시스템을 구축할지 고민해 보겠습니다.

이러한 효율적인 백업 시스템에 대해 나름 고민한 방안에 대해서 아래와 같이 포스팅했는데요. 참고삼아 읽업 보시기 바랍니다.

Dropbox와 구글 드라이브로 구현하는 워드프레스 자동 백업 시스템

11.1. 서버 업체의 정기 백업 서비스 이용

웹호스팅업체는 기본적으로 자체 백업을 해줍니다. 그러나 점차 백업은 사용자의 소관이라는 인식이 늘어나면서 웹호스팅이라도 본인 스스로 백업을 챙겨야 하는 시대입니다. 예전 스마일서브를 사용하던 시기에 백업데이타로 전일치로 돌려달라고 했더니 자기는 1주일전치만 보관한다며 백업을 사용자 소관이라고 (냉냉하게)이야기하더군요. 그럴바에는 왜 웹 호스팅을 이용하는지??

아무튼 가상서버 운영시에는 전부 사용자의 책임이므로 스스로 백업 전체를 챙겨야 합니다.
이런 가상서버에서도 비록 유료이지만 백업 서비스를 이용하는 방법이 있습니다.

앞에서도 소개했지만 Vultr는 매일 백업 서비스는 플랜 가격의 20%를 받습니다. 5$ 플랜는 1$을. 10$ 플랜이라면 2$을 받습니다.

linode를 보니 스탠다드 플랜의 1GB 백업 공간을 제공하는 서비스의 경우 월 2$, 2GB는 2.5$, 4GB는 5$식으로 비용을 받고 있습니다.

11.2. Snapshot 서비스 이용

가상서버 업체별로 Shapsho 기능을 제공하고 있는데요. 특히 Vultr는 11개까지 Snapshot 기능을 무료로 사용할 수 있습니다.
이 Snapshot을 자동으로 만들 수 있으면 금상첨화인데 아직 그런 기능은 없어 주요 작업을 한 이후엔 수작업으로 Snapshot을 만들도록 하면 도움이 많이 됩니다. 특시 서버 작업전에 Snapshot을 떠 놓으면 서버 작업 중 문제를 일으킬 시 바로 복구할 수 있어 엄청 도움이 됩니다.

제가 vultr을 계속 사용하는 이유중의 하나가 바로 이 Snapshot을 무료로 사용할 수 있어서 입니다. 유감스럽게도 다른 업체들 중 만은 업체는 일정 비용을 받습니다.

vultr-%eb%b0%b1%ec%97%85%ea%b0%80%eb%8a%a5%ed%95%9c-%ec%8a%a4%eb%83%85%ec%83%b7snapshots-resize

11.3. 데이타베이스의 정기 백업

데이타베이스는 계속 업데이트되기 때문에 일정 시간단위로 백업을 해놓을 필요가 있습니다.

backup 디렉토리를 만들고 매시간 단위로 백업을 하도록 크론탭 설정합니다.

11.3.1. 백업 디텍토리 및 백업 스크립트 만들기

# mkdir /backup         # backup 디렉토리 만들기
# chmod 700 /backup  # 퍼미션 조정

이어서 백업 스크립트를 만듭니다.

# cd
# nano dbbackup-server.sh   # nano 편집기로 dbbackup.sh를 편집

백업 스크립트 내용은 아래와 같이 만듭니다.

#!/bin/bash
mysqldump --opt --single-transaction -u root -p[password] [database name] > /backup/"[database name]$(date +%Y%m%d%H%M%S).sql
find /backup/ -type f -mtime +48 | sort | xargs rm -f

그리고 백업 스크립트에 실행 권한을 줍니다.

# chmod +x dbbackup-server.sh

11.3.2. 크론탭 설정

크론탭에서 매시간 작업토록 설정

# crontab -e
0 * * * * /root/dbbackup-server.sh 1>/dev/null 2>/dev/null

11.3. 서버 외부로 정기 백업 ; 드롭박스(Dropbox)로 백업 받는 방법

서버내에서 백업을 받아 놓는 것도 필요하지만 백업본을 외부에 정기적으로 백업하는게 필요합니다. 서버 자체가 날라가는 경우를 대비해야 하기 때문이죠.
외부로 백업 받는 방법 중 하나가 드롭박스(Dropbox)를 활용해 여기에 백업 받는 방법이 있습니다. 아래는 그 방법을 간략 설명했습니다.

11.3.1. Dropbox-Uploader 설치

서버에서 드롭박스로 파일을 올려주는 프로그램인 Dropbox-Uploader를 설치 합니다.

cd /usr/bin
git clone https://github.com/andreafabrizi/Dropbox-Uploader/

11.3.2. Dropbox-Uploader 설정

이 다음에는 스크립트에 실행 권한을 부여하고 실행합니다. 처음 실행하면 여러분의 드롭박스 계정에 Dropbox-Uploader를 연결하는 작업을 실행하게 됩니다.

cd /usr/bin/Dropbox-Uploader
chmod +x dropbox_uploader.sh
./dropbox_uploader.sh

이러면 Access token을 입력하라고 하는데요.

Access Token을 받을 수 있는 https://www.dropbox.com/developers/apps로 이동해서

  • 첫번째 단계로 Create App을 선택
  • 둘번째 단계는 이어 나오는 화면에서 API로 ‘Dropbox API app’을 선택하고 Type은 Full Drop Box를 선택하고 적당한 이름(저는 MyUploader_happist라고 했음)을 넣습니다.
  • 세번째 단계는 새로운 App인 MyUploader_happist를 세팅하는 단계로 여기에서 Generated access token 버튼을 눌러서 토큰을 생성합니다. 그러면 아주 긴 토큰이 형성되는데요. 이 토튼을 복사해 터미널에 붙입니다.

11.3.3. 드롭박스 업로드 스크립트

이 단계는 드롭박스 업로더할 업로드 스크립트를 만드는 단계입니다.

# cd
# nano dbbackup.sh   # nano 편집기로 dbbackup.sh를 편집

백업 스크립트 내용은 아래와 같이 만듭니다.

#!/bin/bash
mysqldump --opt --single-transaction -u root -p[password] [database name] > wpbackup.sql
tar -zcvf wpbackup.tgz wpbackup.sql*
#tar -zcvf 'date +%F%T'.tar wpbackup.*
rm *.sql*
/usr/bin/Dropbox-Uploader/dropbox_uploader.sh upload wpbackup.tgz /myDB/"wpbackup$(date +%y%m%d%H%M).tgz"

그리고 백업 스크립트에 실행 권한을 줍니다.

# chmod +x dbbackup.sh

11.3.2. 크론탭 설정

크론탭에서 매일 4시와 21시에 작업토록 설정

# crontab -e
0 4 * * * /root/dbbackup.sh 1>/dev/null 2>/dev/null
0 21 * * * /root/dbbackup.sh 1>/dev/null 2>/dev/null

드롭박스(Dropbox)에 파일을 올릴 수 있도록 설정하는 방법은 복잡하므로 아래 포스팅을 참조해 주시기 바랍니다.

랜섬웨어 대응, 매일 매일 자동으로 드롭박스(Dropbox)로 백업 받는 방법

12. 크론탭 사용에 대해서

리눅스에서 정기 수행 작업 설정 시 사용하는 크롭탭 사용팁에 대해 간단히 정리해 봅니다.

12.1. 실행파일 sh는 복사하지 말것

crontab 설정 시 실행파일 sh 파일을 기존에 만들어 놓은 것을 FTP로부터 복사해 오는 경우가 있습니다 왜 그런지는 모르지만 이렇게 복사해오는 경우 제대로 작동하지 않습니다.
nano 편집기로 바로 만든 실행 파일은 정상적으로 작동하지만, 복사해온 실행 파일은 멀쩡히 해당 디렉토리에 존재하고 파일 권한도 충분하고 소유권도 root로 되어 있어 문제가 없어보이는데 Permission denied, not found같은 메세지를 내 보냅니다.

여러변 테스트를 통해서 내린 결론은 crontab 실행 파일은 서버 세팅 시 새로 만들어야겠다는 결론이었습니다.

조금 귀찮지만 sh 파일을 편지기를 사용해 다시 만들자구요.

12.2. 변경 후 반드시 cron 다시 실행시키기

crontab(크론탭) 명령을 등록 후 반드시 cron을 다시 실행해야 변경 내용에 제대로 반영됩니다.

service cron start  # 가동
또는 
service cron restart # 재가동

12.3. 실행 파일은 일반 경로에 위치, path 설정 – not found

cron은 보안때문에 사용자 개인 설정 파일을 참조하지 않습니다. 즉 사용자의 쉘 초기화 파일(.bashrc, .bash_profile)을 읽지 않습니다.
그러므로 실행 프로그램(예를 들어 *.sh)들은 /usr/bin이나 /bin과 같은 일반 경로에 있어야 cron이 제대로 찾아서 실행시킬 수 있습니다. 이런 경로에 없다면 /bin/sh: 1: /bin/dbbackup.sh: not found 같은 메세지가 메일로 보내집니다.

물론 실행 파일을 root에 놓는다면 문제는 없지만 다른 경로에 놓는 경우는 반듯이 참고해야 합니다.

From: root@root (Cron Daemon)
To: root@root
Subject: Cron <root@root> /bin/dbbackup.sh
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Cron-Env: <path=/bin:/usr/bin:/usr/local/bin:/home>
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>

/bin/sh: 1: /bin/dbbackup.sh: not found

12.4. 실행 파일 권한 문제 – Permission denied

가끔 실행 파일에 제대로 권한이 성정되지 않았다면 아래와 같은 메세지가 메일로 보내집니다.

/bin/sh: 1: dbit.sh: Permission denied

그렇기 때문에 충분한 권한을 줍니다.

chmod +x dbbackup.sh

12.5. crontab 작동 확인 – service cron status

그리고 crontab이 제대로 작동하는지 확인하기 위해서 service cron status 명령을 사용합니다.

service cron status # checks if cron is running

크롭탭에 대한 사용 및 주의점에 대해서는 아래 포스팅을 참조하세요

서버에서 자동 실행을 가능케 해주는 crontab(크론탭) 설정 방법

웹서버 자동 실행 crontab(크론탭) 적용 시 문제점과 해결 방안

13. 마치며

이상으로 간략히 가성서버를 이용해 워드프레스를 운영하는 방안에 대해 정리를 해보았습니다. 원래 시작했던 원대한 계획은 다 사라지고 기능적인 나열에 그쳤다는 생각이 듭니다만 앞으로 틈을 내어 조금씩 업데이트를 하도록 하겠습니다.

아무쪼록 도움이 되었으면 좋겠습니다.

10$ 제휴 프로모션으로 Vultr 가입하기