잡동사니 IT 저장소

개요

이번 글에서는 Apache의 메인 설정 파일인 httpd.conf의 설정 요소에 대해서 알아보고자 한다.

Apache docs에 따르면 httpd.conf에 설정할수 있는 요소는 수백가지가 있지만 모두 정리할 수는 없으므로 기본적인 요소만 정리하도록 하겠다.

처음 보는 사용자의 이해를 돕기 위해 파일의 위에서 아래쪽 순으로 요소를 정리하였다.

httpd.conf 파일은 #을 주석으로 사용한다.

아래의 경우에는 #이 붙은 /apache 를 무시하고 /home/apache를 ServerRoot로 사용한다.

구성 요소

directive라는 공식 문서의 표현에 맞게 구성 요소를 지시자라고 명명하겠다.

ServerRoot

• Apache 서버가 존재하는 디렉토리를 설정한다.
• 일반적으로 하위 디렉토리 conf와 logs를 포함한다.
• 다른 지시자의 상대 경로는 ServerRoot를 기준으로 지정된다.
• 초기값은 Apache를 컴파일하여 설치할 때 prefix로 지정한 경로이다.

Listen

• Apache와 통신하는 특정한 포트를 설정한다.
• Listen 지시자가 설정되어있지 않으면 Apache가 시작되지 않는다.

LoadModule

• ${ServerRoot}/modules 디렉토리 안에 있는 모듈을(so 파일)을 읽어들이고, 사용 가능한 모듈 목록에 추가한다.

<IfModule>

• 특정 모듈이 존재하는 경우에만 작동하는 지시자를 설정하기 위해 사용된다.
• 해당 모듈이 존재하지 않는다면 IfModule 태그 안의 모든 설정 무효화된다.

ServerAdmin

• 서버에서 오류가 발생했을때 클라이언트로 전송하는 오류 메세지에 들어갈 이메일 주소를 설정한다.

ServerName

• 서버가 자신을 식별하기 위해서 사용하는 호스트 이름 및 포트를 설정한다.
• 등록된 DNS 이름을 가지고 있지 않다면 IP 주소로 설정해야 한다.
• ServerName을 서버가 확인할 수 없는 IP 주소로 설정하면 Apache 구동 시 경고 메세지를 표시하고, 시스템에서 사용할 수 있는 모든 호스트 이름을 사용한다.

DocumentRoot

Apache가 제공하는 웹 어플리케이션 디렉토리를 설정한다.

DocumentRoot 마지막에 슬래시(/)를 지정해서는 안된다.

<Directory>

• 해당 디렉토리 경로 또는 와일드카드, 정규 표현식으로 설정된 디렉토리 또는 파일에 적용되는 옵션을 설정한다.
• 경로를 "/" 로 설정하면 모든 디렉토리에 적용되는 옵션을 설정한다.

다음은 <Directory> 태그 안에서 설정할 수 있는 지시자들이다.

• Options : 특정 디렉토리에서 사용할 수 있는 서버 기능을 제어한다.
• AllowOverride : .htaccess 파일의 사용 여부를 결정한다. (All | None)
• Require : 해당 디렉토리의 접근 허용 여부를 설정한다.

DirectoryIndex

• 클라이언트가 파일이 아닌 디렉토리 경로를 요청했을 경우 제공할 파일 목록을 설정한다.
• 예) DirectoryIndex가 index.html로 설정되었으면, 클라이언트가 example.com/abc 를 요청했을 때 abc 디렉토리의 index.html를 찾아서 반환한다.

<Files>

• 해당 파일 경로, 와일드카드 또는 정규 표현식으로 설정된 파일에 대한 옵션을 설정한다.
• 주로 접근 권한이 설정된다.

ErrorLog

• Apache 에러 로그가 생성될 경로를 지정한다.

LogLevel

• ErrorLog의 로그 수준을 설정한다.

LogFormat

• 커스텀 로그에 사용되는 로그 형식을 설정할 수 있다.
• 설정한 로그 포맷에 이름을 설정하여 간단하게 저장하고 사용할 수 있다.

CustomLog 

• Access 로그 파일이 저장되는 위치와 포맷을 설정한다.
• LogFormat에서 지정한 포맷을 이름으로 불러와서 사용할 수 있다.

Alias

• DocumentRoot 하위에 존재하지 않는 디렉토리나 파일에 접근해야하는 경우에 사용한다.

AddType

• Apache에서 사용할 media-type과 확장자를 매핑하여 추가한다.

AddEncoding

• Apache에서 사용할 인코딩과 확장자를 매핑하여 추가한다.

ErrorDocument

• 에러가 발생했을 때 서버가 클라이언트에게 반환할 것을 설정한다.
• 서버는 클라이언트에게 1. 에러 메세지 내역 2. 간단한 텍스트 3. 내부 에러 페이지 4. 외부 에러 페이지를 반환할 수 있다.
• 각 HTTP 상태 코드 별로 반환할 수 있다.

Include

• httpd.conf가 아닌 다른 설정 파일(httpd-mpm.conf, httpd-vhost.conf 등)을 포함하여 적용한다.

참조

Apache Docs Directives : https://httpd.apache.org/docs/2.4/mod/core.html

개요

회사에서 진행하는 프로젝트에서 Apache Axis2를 사용하게 된 적이 있었다.

당시의 나는 SOAP, REST와 같은 웹 서비스에 대한 개념이 부족하여 여기저기 찾아보고는 했는데, 그때 조사한 내용을

이 글에 작성하고자 한다.

웹 서비스란?

• 웹 서비스는 네트워크 상에서 상호운용 가능한 기계 간의 통신을 지원하도록 설계된 소프트웨어 시스템
• Machine-Processable 포맷 (WSDL)으로 기술된 인터페이스이다.
• 다른 시스템들은 일반적으로 XML 직렬화로 HTTP를 사용하여 전달되는 SOAP 메시지를 사용하여 웹 서비스와 상호작용한다.
• 월드 와이드 웹(WWW)과는 달리 웹 서비스는 순수 컴퓨터와 컴퓨터간의 상호작용을 위한 시스템이다.
• 2002년에는 3가지 주요 표준(SOAP, WSDL, UDDI) 모두를 사용하는 것을 웹 서비스라고 정의하였으나, 2003년부터 어느 한가지만을 사용해도 웹 서비스를 구현한 것으로 정의하고 있다.

웹 서비스의 등장 배경

기존의 통합 방식

• 서로 다른 플랫폼 기반 어플리케이션 간 통신 수단이 상이하여 통합이 사실상 어려움
• 통합을 위해 EDI, VAN, Adapter, EAI/B2Bi 등 proprietary한 기술/솔루션을 적용하거나 전면 재개발
• → 많은 시간, 투자, 리소스가 요구

웹 서비스의 등장

• 인터넷과 XML 기반 SOAP과 같이 표준화된 통신 수단을 사용하여 서로 다른 플랫폼 기반 어플리케이션간 통신이 가능해짐
• → 별도의 솔루션을 도입할 필요 없이 통합이 가능해져 비용과 시간을 절약

웹 서비스의 특징

• 시스템 구조의 유연성 : 메인 프레임 또는 서버-클라이언트 방식과 달리 유연한 소프트웨어 구조를 통해 이질적인 데이터 표준을 유연하게 통합/운영
• 사용의 편리성 : 사용자는 소프트웨어를 설치한 후 자연스럽게 서비스를 제공받게 되며, 인터넷을 연결할 수 있는 유/무선 단말기를 통해 장소에 관계없는 접근 가능
• 기존 시스템의 통합 환경을 제공 : 이질적인 어플리케이션간의 통합 서비스를 제공받을 수 있고, 새로운 시스템과의 통합도 자동적으로 이루어진다.
• 비용 효율적 : 분산 시스템의 소프트웨어 간 통합을 자동화적으로 이행해줌으로써 개별 기업마다 투입해야 하는 IT 개발 및 운영 비용을 절감

웹 서비스의 구성 요소

웹 서비스의 구성요소로는 크게 SOAP, WSDL, UDDI 세가지가 있다.

WSDL(Web Service Description Language)

• 웹 서비스를 표현하고 기술하는 언어(서비스 표현 언어)
• 웹 서비스의 공개 인터페이스를 설명하기 위한 XML 문법
• 공개 인터페이스
  • 공개적으로 사용할 수 있는 기능들의 정보
  • XML 메시지를 위한 데이터 타입 정보
  • 사용된 전송 프로토콜에 관한 바인딩 정보
  • 특정한 서비스 위치에 관한 주소 정보
• WSDL은 SML(Service Metadata Locator) 메시지 시스템에 꼭 필요한 것은 아니지만 SOAP 메시지를 기술하기 위한 빌트인 익스텐션(built-in extensions)을 포함하고 있다.

UDDI(Universal Description, Discover and Integration)

• 필요한 서비스를 찾을 수 있는 웹 서비스 레지스트리 (서비스 등록, 검색)
• 웹 서비스와 비즈니스를 발행(Publish) / 검색(Find)하기 위한 기술적인 스펙
• UDDI 데이터 범주
  • White 페이지 : 회사에 대한 일반적인 정보 (비즈니스 이름, 세부내용, 주소)
  • Yellow 페이지 : 회사나 서비스가 제공하는 분류된 데이터 (표준 분류법을 토대로 산업, 제품, 지리적 코드 별로 나뉜 데이터)
  • Green 페이지 : 웹 서비스에 대한 기술적인 정보 (외부 스펙을 가리키거나 웹 서비스 호출에 대한 주소)

SOAP(Simple Object Access Protocol)

• SOAP은 SOA(서비스 지향 아키텍처)와 SOA와 관련된 웹 서비스 규격의 필수적인 부분이다.
• 발신자와 수신자 사이의 메시지 경로를 만들어 주기 때문에 안전을 준수하는 접속, 접속 제어, 신뢰성 있는 전달과 오류 복구, 동적 서비스 발견 등을 지원한다.
• SOAP의 메시지는 XML에서 high-level로 정의되지만, 대부분의 SOAP 어플리케이션은 XML로 작성된 WSDL을 사용한다.
• SOAP의 데이터 구조는 XML을 기반으로 하고 있는데, 이는 웹 페이지를 정의하는데 사용되는 HTML과 여러 면에서 유사하다.
• XML은 대체로 사람이 읽을 수 있어 SOAP 메시지를 쉽게 이해할 수 있게 하지만, 이진 데이터를 수용하는 CORBA 및 RPC 프로토콜에 비해 상대적으로 메시지를 크게 만든다.
• SOAP의 가장 큰 단점은 헤비급 아키텍처를 위한 헤비급 프로토콜이라는 것이다. 메시지가 일련의 노드를 통과하여 각각 처리되어야 한다는 개념은 소프트웨어에 대한 프로토콜과 서비스 버스 아키텍처 모델을 혼합한 것으로 보이며, 그 두 가지 모두 오늘날 일반적으로 사용되는 마이크로 서비스 기반 개발에 최적으로 간주되지 않는다.  

REST(Representational State Transfer)

• REST는 웹 서비스 개발을 위한 아키텍처 스타일이다.
• REST는 새로운 표준, 프레임워크 및 기술을 만드는 것이 아니라 인터넷 HTTP의 기존 시스템과 특징을 기반으로 구축되며 단순하다는 것 때문에 인기가 매우 높다.
• Client-Server의 관점에서 REST의 주된 장점은 HTTP 사용에 익숙한 사람들에게 익숙한 구조를 사용하여 REST 기반 상호작용이 일어난다는 것이다. (REST 기반 상호작용이 모두 표준 HTTP 상태 코드를 사용하여 상태를 나타냄)
• 또한 암호화나 데이터 무결성 등의 세부 사항은 새로운 프레임워크나 기술을 사용하는 것이 아닌 SSL 암호화 및 TLS에 의존함으로써 해결한다. 그러므로 REST 아키텍처는 대부분의 개발자들이 이미 친숙한 개념으로 여길 수 있다.
• REST는 언어에 독립적이다. Java, Kotlin, .NET, AngularJS, JavaScript 등 어떤 언어로도 작성할 수 있으며 프로그래밍 언어가 HTTP를 사용하여 웹 기반 요청을 할 수 있는 한, 그 언어를 사용하여 RESTful API나 웹 서비스를 호출하는 것이 가능하다.

• REST를 사용하는 것의 또다른 이점은 이미 만연해 있다는 것이다. 서버 측에는 개발자가 RESTlet, Apache CXF 등 RESTful 웹 서비스를 만들 수 있도록 지원하는 다양한 REST 기반 프레임워크가 있다. 클라이언트 측에는 Jquery, Node.js, Angular, EmberJS와 같은 자바스크립트 프레임워크로 RESTful 웹 서비스를 호출하고, XML, JSON 기반 데이터를 사용하는 표준 라이브러리를 API에 내장하고 있다.

• 그러나 HTTP 구성을 사용하는 REST의 특성상 HTTP의 제한사항이 그대로 REST의 제한사항으로 적용한다는 단점이 있다. 예를 들어 HTTP는 서버에서 클라이언트로 Push 알람을 보내는 매커니즘이 없기 때문에, 서버에 대한 클라이언트측 폴링이나 다른 유형의 웹 후크(Webhook)를 사용하지 않고 서버가 클라이언트를 업데이트하는 유형의 서비스를 구현하기 어렵다.
• 또한 REST의 표준이 아직 확실하게 정해지지 않았기 때문에 개발자들이 RESTful한 소프트웨어를 개발하는 것에 오해를 불러일으키기 쉽다. 

SOAP VS REST

JAX-WS

OXM(Object-XML Mapping)

위 그림과 같이 SOAP은 보내고자 하는 메시지를 포장하는 포장지와 같다.

클라이언트에서 요청을 보낼 때 정보를 XML로 변환시키고 SOAP으로 포장하여 보내면 서버에서는 SOAP을 벗긴 후 내부 XML을 필요한 객체로 변환하는데, 이렇게 객체와 XML을 변환해 주는 것을 OXM(Object-XML Mapping)이라고 부른다.

JAX-WS(Java API for XML – Web Service)

• OXM을 사용하고 SOAP 바인딩을 실현시켜주는 것이 웹 서비스 프레임워크이다.
• 웹 서비스 프레임워크는 JAVA기반의 JAX-WS와 .NET기반의 WCF가 있다.
• JAX-WS의 구현체로는 대표적으로 CXF, AXIS2가 있다.
• 웹 서비스 프레임워크를 통해 웹 서비스의 WSDL 생성과 SOAP 메시지의 바인딩 OXM을 적용하여 웹 서비스의 전반적인 과정을 처리할 수 있다.

참조

https://javabeat.net/webservices-rest-vs-soap/

http://www.jidum.com/jidums/view.do?jidumId=832

http://www.nextree.co.kr/p11842/

http://api.epeople.go.kr/guide/

잘못된 내용이 기재되어있으면 댓글 부탁드립니다!

개요

httpd는 Apache를 실질적으로 실행하는 파일이다.

일반적으로 httpd를 직접 실행하기보다는 Unix 기반에서는 apachectl, Windows 기반에서는 명령 프롬프트(CMD)를 통해 실행한다.

옵션

-d serverroot

ServerRoot 지시어의 기본값을 serverroot로 설정한다.

설정파일에서 ServerRoot 지시어를 사용하여 이 값을 수정할 수 있다.

Apache 설치경로를 지정한다.

-f config

시작할때 config 파일에 있는 지시어를 사용한다.

config가 /로 시작하지 않으면 ServerRoot에 상대경로로 지정된다.

-k start | restart | graceful | stop

Apache를 시작 | 재시작 | 중단한다.

-C directive

설정파일을 읽기전에 directive 지시어를 처리한다.

-c directive

설정파일을 읽기전에 directive 지시어를 처리한다.

-D parameter

서버 시작 혹은 재시작시 선택적으로 명령어를 처리하기위해 설정파일의 <IfDefine> 섹션에 사용할 parameter를 설정한다.

-e level

서버가 시작하는동안 LogLevel을 level로 설정한다.

-E file

서버가 시작하는동안 file로 오류문을 보낸다.

-R directory

서버를 SHARED_CORE 규칙을 사용하여 컴파일한 경우 공유오브젝트파일 directory를 지정한다.

-h

사용할 수 있는 명령행 옵션들의 짧은 요약을 출력한다.

-l

서버에 같이 컴파일한 모듈 목록을 출력한다.

LoadModule 지시어를 사용하여 동적으로 읽어들이는 모듈은 출력하지 않는다.

-L

지시어 목록을 지시어가 받는 아규먼트와 지시어 사용장소와 같이 출력한다.

-M

읽어들인 정적 모듈과 공유 모듈 목록을 출력한다.

-S

설정파일에서 읽어들인 설정을 보여준다 (현재는 가상호스트 설정만을 보여준다).

-t

설정파일의 문법검사만 한다.

프로그램은 문법을 검사한 후 (문법이 올바른 경우) 0이나 (문법에 문제가 있는 경우) 0이 아닌 종료코드로 즉시 종료한다.

-D DUMP_VHOSTS을 사용하면 가상호스트 설정을 자세히 출력한다.

-D DUMP_MODULES를 사용하면 읽어들인 모듈 목록을 출력한다.

-v

httpd의 버전을 출력하고 종료한다.

-V

httpd의 버전과 컴파일 파라미터를 출력하고 종료한다.

-X

디버그 상태로 웹서버를 실행한다.

오직 한 프로세스나 쓰레드로만 서비스하고, 서버는 콘솔에서 떨어지지 않는다.

다음 옵션은 Windows에서만 사용할 수 있다.

-k install | config | uninstall

Apache를 Windows 서비스로 설치한다.

Apache 서비스의 시작 옵션을 수정한다.

Apache 서비스 설치를 지운다.

-n name

Apache 서비스의 이름을 설정한다.

-w

오류가 발생하면 콘솔창을 열어서 오류문을 보여준다.

참조

Apache docs : https://httpd.apache.org/docs/2.4/programs/httpd.html

개요

Apache를 실행하기 위한 스크립트 파일인 apachectl 관련 옵션을 기재한 문서이다.

apachectl과 httpd는 비슷한 기능을 수행하지만 엄연히 다른 파일이다. httpd 관련 옵션은 따로 문서를 작성하여 게시하겠다.

apachectl command  형식으로 실행할 수 있다.

옵션

start

Apache httpd 데몬을 실행한다.

stop

Apache httpd 데몬을 중단한다.

restart

Apache httpd 데몬을 재시작한다.

재시작 할때 자동으로 configtest 명령을 실행하여 설정 파일을 검사한다.

fullstatus

mod_status의 모든 상태 정보를 출력한다.

이 옵션을 사용하기 위해서는 Apache가 mod_status 모듈을 사용하고 리눅스에 lynx와 같은 문자기반 브라우저가 필요하다.

status

간단한 상태 정보를 출력한다.

fullstatus와 비슷하지만 현재 서비스중인 요청 목록을 출력하지 않는다.

graceful

Apache httpd 데몬을 재시작한다.

restart와는 달리 기동중인 Apache의 연결을 종료하지 않고 설정 파일의 변경 정보를 적용한다.

configtest

설정파일의 문법을 검사한다.

설정파일을 읽고 Syntax Ok 혹은 특정 설정오류에 대한 자세한 정보를 알려준다.

startssl

Apache 2.2 이상 버전에서는 더이상 지원하지 않는다.

httpd.conf 파일에 ssl 관련 설정 후 apachectl start 명령으로 실행하도록 하자.

참조

Apache docs : https://httpd.apache.org/docs/2.4/programs/apachectl.html

개요

리눅스 환경에서 아파치(Apache HTTD)를 설치하는 방법은 두가지가 있다.

1. yum을 사용하여 설치하는 다이렉트 설치

2. Apache 인스톨 파일을 컴파일하여 설치하는 컴파일 설치

본 문서에서는 2번의 컴파일 설치에 대해서 다루고자 한다.

설치 환경은 다음과 같다.

- OS : CentOS 6.7

- Apache Version : Apache 2.4.41

설치 전 준비사항

Apache 설치 파일은 아파치 재단 공식 홈페이지에서 다운로드 받을 수 있다.

https://httpd.apache.org/download.cgi

리눅스에 설치해야하니 tar.gz 파일을 다운받도록 한다.

다운로드받은 파일은 WinSCP 또는 FileZilla 와 같은 FTP 프로그램을 통해서 옮기거나 아래와 같이 wget 명령어를 사용하여 바로 받을 수 있다.

• wget http://mirror.navercorp.com/apache//httpd/httpd-2.4.41.tar.gz

파일을 옮겼으니 이제는 압축을 풀어야 한다.

tar 명령어를 사용하여 압축을 풀도록 한다.

• tar xvfz httpd-2.4.41.tar.gz

컴파일을 진행하기 전 추가로 진행해야 하는 작업들이 있다.

리눅스에서 yum 명령어를 사용하여 아래의 패키지들을 설치한다.

• yum -y install gcc-c++
• yum -y install zlib-devel
• yum -y install openssl-devel
• yum -y install expat-devel
• yum groupinstall 'Development Tools'

Apache 2.4는 2.2와 달리 설치 파일에 APR이 내장되어있지 않아서 따로 APR 파일을 다운로드 받아야 한다.

https://apr.apache.org/download.cgi

apr, apr-util 파일을 다운로드 받아서 위와 동일한 방법으로 리눅스에 옮기고 압축을 푼다.

압축을 풀고 생성된 apr, apr-util 두 디렉토리를 Apache 설치 디렉토리의 srclib 디렉토리에 이름을 변경하여 옮겨놓도록 한다. 

• tar xvfz apr-1.7.0.tar.gz
• tar xvfz apr-util-1.6.0.tar.gz
• mv apr-1.7.0 httpd-2.4.41/srclib/apr
• mv apr-util-1.6.0 httpd-2.4.41/srclib/apr-util

여기까지 왔으면 Apache를 설치할 모든 준비가 끝났다.

컴파일 

컴파일 설치의 이점은 본인이 필요한 옵션만을 사용하여 아파치를 설치할 수 있다는 점이다.

아파치 설치 파일 디렉토리에서 다음의 명령어를 사용하여 아파치를 설치하도록 한다.

./configure --prefix=/home/apache --with-included-apr --with-mpm=worker --enable-so --enable-mods-shared=all  --enable-ssl

위의 옵션은 아파치 컴파일 설치의 가장 기초적인 옵션만을 적어놓은 것이다.

각 옵션의 뜻은 다음과 같다.

더 많은 옵션을 알기 위해서는 아파치 공식 다큐먼트를 참조하는 것이 좋다.

https://httpd.apache.org/docs/2.4/programs/configure.html

성공적으로 configure가 완료되었으면 다음과 같이 나올것이다.

make 명령어를 실행하여 설치를 진행하고 완료가 되었으면 make install 명령어를 실행한다.

한번에 진행하려면 make && make install 으로 실행할 수 있다.

오류 없이 진행되었으면 Apache가 정상적으로 설치되었을 것이다.

prefix에 지정한 경로로 이동하여 확인해보도록 하자.

Apache 실행

Apache를 실행해보자!

bin 디렉토리 안의 apachectl 파일을 사용하여 Apache를 실행할 수 있다.

시작은 ./apachectl start, 종료는 ./apachectl stop으로 할 수 있다.

Apache는 기본적으로 클라이언트와 통신하기 위해서 80번 포트를 사용한다.

로컬에서 실행중이라면 localhost, 원격 또는 vmware를 사용중이라면 해당 ip를 브라우저 창에 입력해보자.

It works! 가 표시된다면 정상적으로 Apache가 실행된 것이다!

만약 Apache가 정상적으로 실행되지 않았거나 접속할 수 없다면 대표적으로 세가지 이유가 있다.

1. root권한이 아닌 일반 사용자 권한으로 실행했다.

리눅스에서는 1024번 이하의 Well-Known 포트는 보안을 위해 root 외 사용자가 접근하는것을 금지하고있다.

개발 및 테스트 환경에서는 편의성을 위해 root 권한으로 실행하도록 하자.

2. 이미 80번 포트가 사용중이다.

netstat -na | grep 80 명령어를 사용하여 80번 포트가 이미 사용중인지 확인하도록 하자.

3. 로컬이 아닌 외부에서 접근하는 경우 방화벽이 설정되지 않았다.

CentOS 6 기준으로 방화벽은 iptables 명령어 또는 iptables 파일을 수정하여 변경할 수 있다.

/etc/sysconfig/iptables 파일을 열어서 아래와 같이 설정되어있는지 확인해보자.

방화벽 정보를 변경하였다면 iptables를 다시 시작해서 적용하자.

재시작은 service iptables restart 명령어를 사용하여 할 수 있다.

이상으로 Apache 설치에 대해서 알아보았다.