1. 패키지 관리?

(라떼는)예전에는 Linux에 뭔가를 설치하기 위해서 프로그램 소스를 다운 받아 컴파일 해가며 설치를 해야 했던 때가 있었습니다. 그러나 CentOS와 같은 많은 Linux 배포판에서는 이러한 번거로운 과정을 피하기 위해 패키지 관리자를 제공합니다. 패키지 관리자는 소프트웨어 패키지를 다운로드하고 설치, 업데이트, 제거할 수 있는 도구입니다.

CentOS의 패키지 관리자인 yum(Yellowdog Updater, Modified)은 시스템에서 소프트웨어 패키지를 관리하는 데 사용됩니다. yum은 CentOS 및 기타 RHEL(Red Hat Enterprise Linux) 계열 배포판에서 사용할 수 있으며, 사용자가 원하는 소프트웨어를 쉽게 설치하고 유지 관리할 수 있도록 도와줍니다.

yum은 레파지토리(Repository)라고 불리는 중앙 저장소에서 패키지를 가져옵니다. CentOS에서는 기본적으로 여러 가지 레파지토리가 제공되며, 이러한 레파지토리에서 다양한 소프트웨어 패키지를 검색할 수 있습니다.

Remi 저장소에 대해서

Remi 저장소는 CentOS 및 RHEL (Red Hat Enterprise Linux) 계열 배포판에서 제공되는 외부 저장소 중 하나입니다. 이 저장소는 추가적인 소프트웨어 패키지를 제공하여 사용자가 CentOS 시스템에 최신 소프트웨어를 쉽게 설치하고 유지 관리할 수 있도록 도와줍니다.

Remi 저장소는 특히 웹 서버와 관련된 소프트웨어를 중점적으로 제공합니다. 예를 들어, PHP, MySQL, Nginx 등과 같은 웹 개발에 필요한 패키지를 최신 버전으로 제공합니다. Remi 저장소는 보안 패치와 업데이트를 지속적으로 제공하며, 사용자들이 최신 소프트웨어 버전을 유지할 수 있도록 합니다.

Remi 저장소를 사용하려면 먼저 해당 저장소의 RPM 패키지를 시스템에 설치해야 합니다. 일반적으로 Remi 저장소 RPM 파일은 remi-release-X.rpm과 같은 형식을 가지고 있습니다. 여기서 X는 CentOS 또는 RHEL의 메이저 버전을 나타냅니다. 예를 들어, CentOS 7을 사용하는 경우 remi-release-7.rpm을 사용할 수 있습니다.

이렇게 함으로써 Remi 저장소에서 PHP, NginX등의 패키지 정보를 가져와 최신 버전으로 시스템에 설치할 수 있습니다.

Remi 저장소는 사용자들이 최신 버전의 소프트웨어를 이용할 수 있도록 도와주는 유용한 도구입니다. 그러나 외부 저장소를 추가하는 것은 시스템의 안정성과 보안을 위해 신중하게 검토해야 합니다. 외부 저장소를 추가하기 전에 해당 저장소의 신뢰성과 업데이트 정책을 확인하는 것이 좋습니다.

nginx의 Stable 배포판과 mainline 배포판

Nginx는 오픈 소스 웹 서버 및 리버스 프록시 소프트웨어로, 안정성과 성능을 갖춘 특징으로 유명합니다. Nginx는 두 가지 주요 배포판인 Mainline과 Stable을 제공합니다.

Mainline 배포판:

Mainline 배포판은 Nginx 개발자들이 최신 기능과 개선 사항을 실험하고 테스트하는 데 사용하는 버전입니다. Mainline 배포판은 주기적으로 업데이트 되며, 새로운 기능, 향상된 성능, 보안 패치 등이 추가될 수 있습니다. 주로 개발자, 테스터, 혹은 최신 기능을 적용해야 하는 사용자들에게 권장됩니다. Mainline 배포판은 일부 실험적인 기능을 포함할 수 있기 때문에 안정성에 대한 보장은 없습니다.

Stable 배포판:

Stable 배포판은 더 큰 안정성과 신뢰성을 갖춘 버전으로, 실제 운영 환경에서 사용하기에 적합합니다. Stable 배포판은 운영 환경에서 사용되며, 검증된 기능과 보안 패치를 제공합니다. 버그 수정과 보안 업데이트는 안정 배포판에 우선 적용되며, 대부분의 사용자들에게 추천됩니다. Stable 배포판은 Mainline 배포판에 비해 새로운 기능이나 실험적인 변경 사항이 덜 포함되어 있습니다.

Mainline과 Stable 배포판 중 어떤 버전을 선택할지는 사용자의 요구 사항과 운영 환경에 따라 달라집니다. 개발 중인 새로운 기능을 사용하고자 하는 경우에는 Mainline을 선택할 수 있으며, 안정성과 신뢰성을 우선시하는 경우에는 Stable을 선택하는 것이 좋습니다. 일반적으로, 운영 환경에서는 Stable 버전을 사용하는 것이 권장됩니다.

아래는 두 배포판 중 원하는 배포판을 선택할 수 있도록 설정하는 내용입니다.

보통 실험정신이 투철한 분이나 새로운 기능에 대해서 실험해 보기를 원하는 목적이 아니라면 stable 버전을 사용합니다.

yum-config-manager 명령은 Yum 패키지 관리자의 저장소 구성을 관리하는 데 사용됩니다. --enable 및 --disable 옵션을 사용하여 저장소를 활성화하거나 비활성화할 수 있습니다.

따라서 yum-config-manager --enable nginx-stable 명령은 nginx-stable 저장소를 활성화하는데 사용됩니다. 이 명령을 실행하면 해당 저장소가 사용 가능한 상태가 되어 최신 버전의 Nginx 패키지를 설치하거나 업데이트할 수 있습니다.

반대로, yum-config-manager --disable nginx-mainline 명령은 nginx-mainline 저장소를 비활성화하는 데 사용됩니다. 이 명령을 실행하면 해당 저장소가 비활성화되어 해당 저장소에서 제공되는 Nginx 패키지를 사용할 수 없습니다.

이러한 명령을 사용하여 저장소의 활성화 또는 비활성화 상태를 조정할 수 있으며, 원하는 버전의 Nginx를 설치하고 관리할 수 있습니다.

yum clean all 명령은 yum의 캐시를 정리하는 작업을 수행합니다. yum은 패키지 및 저장소 메타데이터를 로컬 캐시에 저장하여 다운로드 속도를 향상시킵니다. 그러나 때로는 이 캐시가 오래되어 업데이트된 정보를 제대로 반영하지 못할 수 있습니다. yum clean all 명령은 모든 캐시를 제거하고 새로운 정보로 업데이트해야 함을 나타냅니다.

yum update 명령은 시스템에 설치된 모든 패키지를 최신 버전으로 업데이트합니다. 이 명령을 실행하면 CentOS 저장소와 추가된 저장소에서 사용 가능한 패키지의 최신 버전을 확인하고 해당 패키지를 업그레이드합니다. 따라서 시스템에 설치된 모든 패키지가 최신 상태로 업데이트됩니다.

그 후 yum install nginx 명령을 사용하여 Nginx 웹 서버를 설치할 수 있습니다. 이 명령은 yum을 통해 Nginx 패키지를 찾고, 의존성을 확인한 후 필요한 패키지를 자동으로 설치하여 Nginx를 시스템에 설치합니다.

따라서 yum clean all, yum update, yum install nginx와 같은 순서로 명령을 실행하는 것은 시스템을 최신 상태로 업데이트하고 Nginx를 최신 버전으로 설치하기 위한 과정입니다. 이를 통해 최신 보안 패치 및 기능 업데이트를 반영한 안정적인 Nginx 설치를 수행할 수 있습니다.

설치가 마무리 되면 설치된 nginx의 버전을 확인해 봅니다.

[root@comp www]# nginx -v
nginx version: nginx/1.24.0

Orchestration과 nginX proxy(외주)

현재(23. 06. 29) 제가 파악한 GPT기반 API연동 프로젝트에서 실제 product하기에 가장 좋은 기법은 langchain을 이용하는 것입니다. Azure를 활용한 다양한 서비스 개발 기법들이 나오고 있지만 Open Source를 배경으로 하는 langchain의 발전 속도와 다양한 활용 기법들을 따라오기가 현실적으로 어렵습니다. 서버 환경 설정에서 node.js를 설치하여 php와 함께 서비스 구성을 하는 것이 목적입니다. 다만 node.js와 langchain의 연동은 보편화된 서버 세팅은 아니므로 별도의 페이지로 구분하겠습니다.

Nginx를 사용하여 PHP-FPM과 Node.js를 연동하는 경우, Nginx는 프록시 서버 역할을 수행합니다. Nginx는 클라이언트로부터의 요청을 받아들이고, 해당 요청을 PHP-FPM 또는 Node.js로 프록시하여 적절한 처리를 수행합니다.

1. PHP-FPM와의 프록시 연동:
   • 클라이언트가 PHP 파일을 요청할 경우, Nginx는 해당 요청을 받아들입니다.
   • Nginx는 PHP 파일을 처리하기 위해 PHP-FPM에게 프록시 요청을 전달합니다.
   • PHP-FPM은 해당 PHP 파일을 실행하고, 처리 결과를 Nginx로 반환합니다.
   • Nginx는 PHP-FPM으로부터 받은 응답을 클라이언트에게 전달합니다.
2. Node.js와의 프록시 연동:
   • 클라이언트가 Node.js 애플리케이션을 요청할 경우, Nginx는 해당 요청을 받아들입니다.
   • Nginx는 Node.js 애플리케이션을 처리하기 위해 프록시 요청을 Node.js 서버로 전달합니다.
   • Node.js 서버는 요청을 받아 해당 애플리케이션을 실행하고, 처리 결과를 Nginx로 반환합니다.
   • Nginx는 Node.js 서버로부터 받은 응답을 클라이언트에게 전달합니다.

이러한 방식으로 Nginx는 클라이언트와 PHP-FPM 또는 Node.js 서버 사이에서 중계 역할을 수행합니다. 클라이언트는 Nginx에게 요청을 보내고, Nginx는 요청을 적절한 백엔드 서버로 프록시하여 처리 결과를 클라이언트에게 반환합니다.

이와 같은 구성은 여러 가지 이점을 제공합니다:

• 정적(static) 파일 처리: Nginx는 정적 파일 서버로서 효율적으로 클라이언트에게 정적 파일을 제공합니다.
• PHP 처리: Nginx는 PHP 파일을 프록시하여 PHP-FPM에게 전달하고, PHP 코드를 실행하며 응답을 클라이언트에게 반환합니다.
• Node.js 처리: Nginx는 Node.js 애플리케이션을 프록시하여 Node.js 서버에서 실행하고, 응답을 클라이언트에게 전달합니다.
• 로드 밸런싱: Nginx는 요청을 백엔드 서버로 분산시켜 로드 밸런싱을 수행하여 성능과 가용성을 향상시킵니다.
• SSL 암호화: Nginx는 SSL/TLS 암호화를 지원하여 보안된 통신을 제공할 수 있습니다.

이렇게 Nginx를 프록시 서버로 사용하여 PHP-FPM와 Node.js를 연동하는 것은 여러 언어와 기술 스택을 효과적으로 결합하여 다양한 웹 애플리케이션을 호스팅하는 데 사용됩니다. Nginx는 클라이언트 요청을 받아들이고, PHP-FPM와 Node.js 서버로의 프록시 요청을 처리하여 적절한 백엔드 서버에서 애플리케이션을 실행하고 결과를 클라이언트에게 반환합니다.

이러한 프록시 방식은 각 기술 스택의 강점을 활용하면서도 Nginx의 성능과 기능을 활용할 수 있습니다. 예를 들어, 정적 파일 처리와 로드 밸런싱은 Nginx가 가장 효과적으로 수행하며, PHP-FPM와 Node.js 서버는 동적 콘텐츠를 처리하기 위해 특화된 역할을 수행합니다.

프록시 연동의 이점은 다음과 같습니다:

1. 성능: Nginx는 경량 웹 서버로 알려져 있으며, 정적 파일 제공에 탁월한 성능을 발휘합니다. 정적 파일 요청은 Nginx에서 처리되고, 동적 콘텐츠 요청은 백엔드 서버(PHP-FPM 또는 Node.js)로 프록시됩니다. 이렇게 분산되어 처리되는 것으로 성능을 향상시킬 수 있습니다.
2. 유연성: PHP-FPM와 Node.js는 각각의 특정 언어와 프레임워크를 지원하는 강력한 도구입니다. 프록시를 사용하여 각 기술 스택을 연동하면, 서로 다른 요구사항을 가진 웹 애플리케이션을 동시에 호스팅할 수 있습니다.
3. 로드 밸런싱: Nginx는 프록시를 통해 백엔드 서버로 요청을 분산시킬 수 있습니다. 이를 통해 트래픽 부하를 분산하고, 가용성을 향상시킬 수 있습니다. PHP-FPM와 Node.js 서버를 여러 개 운영하고, Nginx가 로드 밸런싱을 수행하도록 구성할 수 있습니다.
4. 보안: Nginx는 보안 기능과 SSL/TLS 암호화 지원을 통해 안전한 통신을 제공할 수 있습니다. 프록시를 통해 클라이언트와 백엔드 서버 사이에 추가적인 보안 계층을 구성할 수 있습니다.

이러한 방식으로 Nginx를 프록시 서버로 사용하여 PHP-FPM와 Node.js를 연동함으로써 다양한 웹 애플리케이션을 호스팅하고, 각각의 기술 스택을 효과적으로 활용할 수 있습니다.

우선 PHP-FPM 설치하기(FastCGI?)

라떼는 Apache에 모듈 형식으로 php를 운영하던 때가 있었습니다. 이 바닥 고인물들은 apache를 컴파일하기 길다란 옵션속에 php 및 관련 모듈의 목록을 적어 넣던 기억을 가지고 있을 것입니다.

이러한 방식은 모듈 및 모듈 연동의 문제가 웹서버 전체에 영향을 미치게 됩니다. 더하여 요즘은 웹페이지 하나에도 다양한 서비스들이 녹아 있는 복잡한 형태를 띄고 있기 때문에 서비스들을 독립적으로 구성하여 상호간 영향을 덜 미치게 하는 방식이 선호됩니다. 이를 위해 FastCGI가 등장하게 됩니다.

FastCGI는 웹 서버와 웹 애플리케이션 간의 통신을 위한 프로토콜입니다. FastCGI는 웹 서버와 애플리케이션 간의 연결을 지속적으로 유지하고, 여러 요청을 동시에 처리할 수 있는 확장성과 성능을 제공합니다.

FastCGI의 장점은 다음과 같습니다:

성능: FastCGI는 모듈 형식에 비해 더 나은 성능을 제공합니다. FastCGI는 웹 서버와 애플리케이션 간의 연결을 유지하는 Keep-Alive 연결을 사용하므로, 애플리케이션 실행에 필요한 부하가 감소합니다. 이로 인해 빠른 응답 시간과 더 많은 동시 요청 처리가 가능해집니다.

확장성: FastCGI는 별도의 프로세스나 서버로 실행되므로, 웹 서버와 애플리케이션 간의 통신에 높은 확장성을 제공합니다. 웹 서버와 애플리케이션은 독립적으로 확장하거나 스케일 아웃할 수 있으며, 이는 웹 트래픽의 증가나 애플리케이션의 부하 분산에 유리합니다.

다양한 언어 지원: FastCGI는 다양한 프로그래밍 언어와 플랫폼을 지원합니다. PHP, Python, Ruby, Perl 등 다양한 언어의 애플리케이션을 FastCGI 인터페이스로 실행할 수 있습니다. 이는 다양한 개발 스택과 팀의 선호도에 따라 유연한 선택을 가능하게 합니다.

보안: FastCGI는 애플리케이션과 웹 서버 간의 분리를 통해 보안을 강화합니다. 웹 서버는 클라이언트와 직접적으로 통신하고, 애플리케이션은 웹 서버를 통해 간접적으로 요청을 받습니다. 이로 인해 애플리케이션의 실행 환경을 분리하고, 웹 서버의 보안 설정을 적용하여 애플리케이션을 보호할 수 있습니다.

yum repolist enabled | grep remi-php 명령은 현재 사용하도록 설정된 php 버전을 확인합니다. 현재 8.2 버전을 설치하고 있는데 원하지 않는 버전이 목록에 있다면 yum-config-manager 를 통하여 –disable 하면 되겠죠.

사용할 버전을 선택했다면 php-fpm을 비롯한 관련 extension들을 설치하면 됩니다. extension들은 php 버전에 종속되어 함께 관리됩니다.

NginX, PHP-FPM 연동 설정

NginX와 이러한 방식은 모듈 및 모듈 연동의 문제가 웹서버 전체에 영향을 미치게 됩니다. 더하여 요즘은 웹페이지 하나에도 다양한 서비스들이 녹아 있는 복잡한 형태를 띄고 있기 때문에 서비스들을 독립적으로 구성하여 상호간 영향을 덜 미치게 하는 방식이 선호됩니다. 이를 위해 FastCGI가 등장하게 됩니다.

FastCGI는 웹 서버와 웹 애플리케이션 간의 통신을 위한 프로토콜입니다. FastCGI는 웹 서버와 애플리케이션 간의 연결을 지속적으로 유지하고, 여러 요청을 동시에 처리할 수 있는 확장성과 성능을 제공합니다.

FastCGI의 장점은 다음과 같습니다:

성능: FastCGI는 모듈 형식에 비해 더 나은 성능을 제공합니다. FastCGI는 웹 서버와 애플리케이션 간의 연결을 유지하는 Keep-Alive 연결을 사용하므로, 애플리케이션 실행에 필요한 부하가 감소합니다. 이로 인해 빠른 응답 시간과 더 많은 동시 요청 처리가 가능해집니다.

확장성: FastCGI는 별도의 프로세스나 서버로 실행되므로, 웹 서버와 애플리케이션 간의 통신에 높은 확장성을 제공합니다. 웹 서버와 애플리케이션은 독립적으로 확장하거나 스케일 아웃할 수 있으며, 이는 웹 트래픽의 증가나 애플리케이션의 부하 분산에 유리합니다.

다양한 언어 지원: FastCGI는 다양한 프로그래밍 언어와 플랫폼을 지원합니다. PHP, Python, Ruby, Perl 등 다양한 언어의 애플리케이션을 FastCGI 인터페이스로 실행할 수 있습니다. 이는 다양한 개발 스택과 팀의 선호도에 따라 유연한 선택을 가능하게 합니다.

보안: FastCGI는 애플리케이션과 웹 서버 간의 분리를 통해 보안을 강화합니다. 웹 서버는 클라이언트와 직접적으로 통신하고, 애플리케이션은 웹 서버를 통해 간접적으로 요청을 받습니다. 이로 인해 애플리케이션의 실행 환경을 분리하고, 웹 서버의 보안 설정을 적용하여 애플리케이션을 보호할 수 있습니다.

여기부터는 정말 case by case 입니다. 위 설정을 적용하기 위해 자기 상황별로 아래 작업들을 수행해야 합니다:

• 도메인 정보의 변경: somedomain.kr로 되어 있는 부분을 본인의 도메인으로 바꿔야 합니다. 가상 호스트 형식으로 한 서버에서 여러개의 사이트를 운영하는 경우 홈디렉토리명과 도메인을 직관적으로 인식할 수 있도록 일치시키는 것이 좋습니다.
• /www 디렉터리 생성: Nginx의 루트 디렉터리로 사용할/www 디렉터리를 생성해야 합니다. 필요에 따라 권한을 설정하여 Nginx 프로세스가 해당 디렉터리에 접근할 수 있도록 해야 합니다.
• /www/somedomain 디렉터리 생성: 웹 파일을 배치할 디렉터리인 /www/somedomain을 생성해야 합니다. 이 디렉터리는 Nginx의 root 설정에 해당하며, 웹 애플리케이션 파일을 해당 디렉터리에 배치해야 합니다.
• /www/_session 디렉터리 생성: PHP 세션 데이터를 저장할 디렉터리인 /www/_session을 생성해야 합니다. 해당 디렉터리는 PHP-FPM 설정에서 session.save_path로 사용됩니다.
• 에러 로그 디렉터리 생성: /www/_log/nginx 디렉터리를 생성하고, 그 안에 somedomain-error.log 파일을 생성해야 합니다. 해당 파일은 Nginx의 에러 로그를 기록하기 위한 파일입니다. 권한 설정에 주의하여 Nginx 프로세스가 해당 디렉터리와 파일에 쓰기 권한을 가지고 있어야 합니다.
• PHP-FPM 연결 정보 확인: 현재 설정에서는 PHP-FPM 소켓 정보가 127.0.0.1:9000으로 설정되어 있습니다. 이는 PHP-FPM이 로컬에서 9000 포트에서 실행되고 있음을 가정한 것입니다. 만약 PHP-FPM이 다른 호스트 또는 포트에서 실행되고 있다면 해당 정보로 설정을 변경해야 합니다.

위 작업들을 진행한 후, Nginx 설정 파일을 저장하고 Nginx를 재시작하여 변경 사항이 적용되도록 해야 합니다. 변경된 설정에 맞게 웹 파일을 해당 디렉터리에 배치하고, PHP-FPM을 구성하여 PHP 파일을 처리할 수 있도록 해야 합니다.

nginx와 php-fpm을 재시작합니다. enable 옵션을 사용하면 부팅시 자동시작 항목으로 들어갑니다. 현재 서버에 아무런 서비스가 운영되고 있지 않다면 꼭 재시작해서 정상 작동을 확인하는 게 좋습니다.

user와 group을 nginx로 설정하였습니다. 이 설정은 PHP-FPM 프로세스가 실행될 때 해당 사용자와 그룹으로 실행되도록 지정하는 것을 의미합니다.

기본적으로 PHP-FPM은 특정 사용자와 그룹으로 실행되며, 이는 보안 및 파일 시스템 권한 관리를 위한 중요한 요소입니다. 기본 설정에서는 주석 처리되어 있던 user 및 group 설정을 주석 해제하고 nginx로 변경하였습니다.

일반적으로 Nginx 웹 서버는 nginx 사용자와 nginx 그룹으로 실행되며, PHP-FPM도 이와 동일한 사용자 및 그룹을 사용하여 일관성을 유지합니다. 따라서, PHP-FPM 프로세스가 Nginx와 동일한 권한으로 실행되도록 user와 group을 nginx로 설정한 것입니다.

이렇게 함으로써 Nginx와 PHP-FPM은 동일한 사용자 및 그룹으로 실행되므로 파일 및 디렉터리의 소유자와 권한을 적절히 관리할 수 있습니다. 이는 보안 및 권한 관리 측면에서 중요하며, 웹 서버와 PHP-FPM 간의 통신 및 파일 접근에 일관성을 제공합니다.

nginx와 php-fpm을 재시작합니다. enable 옵션을 사용하면 부팅시 자동시작 항목으로 들어갑니다. 현재 서버에 아무런 서비스가 운영되고 있지 않다면 꼭 재시작해서 정상 작동을 확인하는 게 좋습니다.

MariaDB는 MySQL과 호환되는 DBMS(데이터베이스 엔진)로, 다음과 같은 장점을 가지고 있습니다:

1. 호환성과 대체 가능성: MariaDB는 MySQL과 완전히 호환되는 데이터베이스 엔진입니다. 따라서, 기존에 MySQL을 사용하던 애플리케이션 및 도구를 그대로 사용하면서 MariaDB로 전환할 수 있습니다. 이는 기존 MySQL 사용자들에게 유리한 점입니다.
2. 개선된 성능과 최적화: MariaDB는 MySQL과 비교하여 몇 가지 최적화 및 성능 개선이 이루어졌습니다. 특히, 스토리지 엔진과 쿼리 옵티마이저의 성능이 향상되었습니다. 이로 인해 애플리케이션의 성능과 응답 시간이 향상될 수 있습니다.
3. 개방적인 개발: MariaDB는 개방적인 개발 프로세스와 활발한 커뮤니티를 가지고 있습니다. 개발자들은 MariaDB에 자유롭게 기여하고 코드를 개선할 수 있으며, 이는 빠른 혁신과 기능 개선에 기여합니다. 이는 더욱 유연하고 개방적인 환경에서 개발 및 운영을 진행할 수 있음을 의미합니다.
4. 추가적인 보안 기능: MariaDB는 MySQL에 비해 추가적인 보안 기능을 제공합니다. 데이터 암호화, 개인 정보 보호, 연결 보안 등의 기능을 향상시킬 수 있습니다. 이는 중요한 데이터의 보안을 강화하고 개인 정보를 보호하는 데 도움이 됩니다.

위의 장점을 고려하여 MariaDB를 선택하면 MySQL과의 호환성을 유지하면서 개선된 성능, 개방적인 개발 환경, 추가적인 보안 기능 등을 경험할 수 있습니다.

MariaDB는 yum의 기본 패키지에 포함되어 있지만 그대로 설치하면 옛 버전이 설치됩니다. MariaDB 배포 repository를 설정하면 최신 버전을 설치할 수 있습니다.

https://archive.mariadb.org/ 에 가보시면 많은 버전이 있습니다. 버전을 확인한 후 원하는 버전의 경로를 기재하면 됩니다. 다만 최신버전 일부는 yum을 지원하지 않는 경우가 있으니 해당 디렉토리에 yum 디렉토리가 있는지 확인하여야 합니다.

저는 11.x 버전 설치를 하지 않고 10.9.7 버전을 설치하고 있는데 DB의 경우 보수적으로 접근하는 경향이 있는 것 같습니다. 마루타는 싫으니까. 11버전에서 MariaDB는 MySQL의 그늘을 벗어나고자 하는 노력들을 많이 보여주고 있습니다.

설치가 완료되면 MariaDB 설정파일에서 charset을 바꿔줍니다. 기본은 latin1이기 때문에 추후 저장된 텍스트가 깨지거나 하는 경험을 하고 싶지 않으면 기본적으로 해주는 것이 좋습니다.

MariaDB 역시 동일하게 서비스를 시작해 주고 부팅시 자동 시작 서비스에 등록해 줍니다.

MariaDB도 MySQL과 동일하게 기본 셋팅을 할 수 있는 스크립트가 있습니다. 아래 스크립트를 실행하면 초기 설정을 할 수 있습니다.