linuxer-admin

ALB sticky session 에 대한 고찰.

aws 에선 고가용성을 위한 로드벨런서를 지원한다.

로드벨런서의 이야기다.

오늘 3티어 구성에서 세션이 널뛰는 증상이 있었다. 그 이야기를 하기전에 먼저 설명부터 하겠다.

ELB 라는 이름으로 ALB/NLB/CLB로 불린다.

Application Load Balancer, Network Load Balancer, Classic Load Balancer 이다.

오늘 이야기할 로드벨런서는 ALB인데 그중에도 sticky session 이다.

한글 콘솔에서는 고정 세션이라 불린다. 고정세션은 라운드 로빈으로 작동하는 로드벨런서에 세션을 고정해서 사용자의 경험을 지속할수 있도록 도와주는 역할을 한다.

먼저 옵션을 설정하는 방법부터 보자

로드벨런서>대상그룹> 속성편집 을 누른다.

그럼 아래와 같은 창이뜨고 활성화를 누르면 고정세션의 시간을 활성화 할수 있다.

활성화 한 화면은 다음과 같다.

sticky session 이 정상적으로 붙은지 확인하는 방법은 아래와 같다.

아직 sticky session 설정을 추가하지 않은상태다.

sticky session 세션은 cookie로 생성이된다.

Application Load Balancer는 로드 밸런서가 생성한 쿠키만 지원합니다. 쿠키의 이름은 AWSALB입니다. 이러한 쿠키의 콘텐츠는 교체 키를 사용하여 암호화됩니다. 로드 밸런서가 생성한 쿠키는 해독하거나 변경할 수 없습니다.

https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/load-balancer-target-groups.html#sticky-sessions

3tier로 구성하면 AWSALB 쿠키가 2개가 붙는다.

AWSALB fnCHt1XmAslF4YJP1DdrFja2gFlp58fwxawbSD63gMsYHbSY6ZvL47TP9JyNb1LAqNBb1mt3J0xTVTQrbyFV3KVQmFayhf0C+FIcsOoXDpadKRTlRxNiL2jaijXf N/A N/A N/A 131
JSESSIONID BA145F75466D30D122F5BF83873E0C13 N/A N/A N/A 45
_ga GA1.3.549999545.1568632026 N/A N/A N/A 32
Response Cookies 357
AWSALB 7/4O7AyBPsXTcT9Y3AEE+B3ueRztLwkdTz9TwF/bJ191ItEAMN1HoOk1xsVtWsOjbmuZb68s5gs+6xM2oowR3JgexIIVYIUPWwFkkOWliy3FkwsmeMzQmXsKAkV0 / 2019-10-28T10:50:30.000Z 179
AWSALB UUu3Vbr3MNNBSaaby5Z1dduf11BTf0148wbnE+20aF9Ak+QQWv0ZFGlsBsUZTOWRB9k99mVsAzr0PMgLAiciFD5mJW2FLmNn3ojwbh/EEQFdL5qe6NZCkAFKuLOz / 2019-10-28T10:50:30.000Z 178

alb-web-alb-was-rds 구성이면 쿠키가 좀붙는데 was 가 tomcat 라면

awsalb 쿠키 2개와 jsessoinid 라는 쿠키까지 붙는다.

여기서 awsalb 쿠키는 response 한 alb쿠키를 request 에 재활용한다.

awsalb 쿠키는 지속적으로 변한다. 하지만 sticky session 에의해서 jsessionid값은 연결된 was의 고유값을 지니며 jsessionid 가 변경되면 세션이 초기화 되서 재 매칭이 된다.

이걸 왜포스팅하냐면 sticky 가 정상적으로 붙는데 세션이 was1/2로 붙는 증상이 발생해서 확인하는 방법을 포스팅한거다..

아디오스!

2019년 10월 21일 by AWS 9

RDS CA 인증서 2015 -> 2019 변경

메일을 받았다.

Hello,

Please act before October 31, 2019 to address an upcoming interruption of your applications using RDS and Aurora database instances.

To protect your communications with RDS database instances, a Certificate Authority (CA) generates time-bound certificates that are checked by your database client software to authenticate any RDS database instance(s) before exchanging information. Following industry best practices, AWS renews the CA and creates new certificates on a routine basis to ensure RDS customer connections are properly protected for years to come. The current CA expires on March 5, 2020, requiring updates to existing RDS database instances with certificates referencing the current CA.

You are receiving this message because you have an Amazon RDS database instance(s) in the AP-NORTHEAST-1, AP-NORTHEAST-2, AP-SOUTHEAST-1, AP-SOUTHEAST-2 Region(s). If your applications connect to those instances using the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocol please follow the detailed instructions in the link below to complete your update(s). If not completed, your applications will fail to connect to your DB instances using SSL/TLS after March 5, 2020.

We encourage you to test these steps within a development or staging environment before implementing them in your production environments. Beginning today, you can start testing and updating your existing RDS database instances. For detailed instructions, please visit: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL-certificate-rotation.html

Any new RDS instances created after November 1, 2019 will default to using the new certificates. If you wish to temporarily modify new instances manually to use the old (rds-ca-2015) certificates, you can do so using the AWS console or the AWS CLI. Any instances created prior to November 1, 2019 will have the rds-ca-2015 certificates until you update them to the rds-ca-2019 version.

If you have questions or issues, please contact AWS Support at: https://aws.amazon.com/support

Sincerely,
Amazon Web Services

rds의 ca 인증서가 2015에서 2019로 변경되었다. 간단한 테스트를 진행할거고 변경을 진행할것이다.

먼저 진행할 테스트는 ca-2015 인증기관과 중간 인증서로 접속하기다. 처음엔 글로벌 CA를 이용할거라 생각했는데 아니었다. 리전마다 중간인증서로 명명된 CA인증서를 사용해야 한다.

접속 정보는 이미 모두 적용된 세션에 SSL CA 만 추가해서 접속한다

사용한 인증서는 RDS 에선 CA-2015 그리고 SSL CA인증서는 아마존에서 제공하는 중간인증서를 사용하였다.

https://s3.amazonaws.com/rds-downloads/rds-ca-2015-ap-northeast-2.pem

위 인증서를 받아서 접속을 하였다.

/* 구분자를 ";" 으(로) 변경 / / linuxer-blog-rds.ctekipxl.ap-northeast-2.rds.amazonaws.com 에 MariaDB (SSH tunnel) 을(를) 통해 연결 중, 사용자 이름 "admin", 암호 사용: Yes… / / SSL 매개 변수를 성공적으로 설정하였습니다. / / Attempt to create plink.exe process, waiting 4s for response … / /
/ SELECT CONNECTION_ID(); / 연결됨. 스레드-ID: 579 / / 문자 집합: utf8mb4 */

정상적으로 접근이 가능한것을 확인하였다.

인증서 다운로드 리스트는 아래의 링크이다.

https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html

그럼 이제 테스트할것은 RDS CA-2015 을 CA-2019 로변경하고 rds-ca-2015-ap-northeast-2.pem 인증서로 접근해 볼것이다. 인증기관을 변경하는 방법은 다음과 같다.

수정을 누르고~ 스크롤을 내린다.

인증기관 부분을 2015 -> 2019로 변경한다.

변경하면 위와같은 노티가 발생한다. 새인증서를 받아서 사용하라는 메시지 이다.

2분가량의 다운 타임이 발생하고 이테스트를 진행하는 이유는 다음 글귀 때문이다.

aws docs 에서 본 글귀인데

이 루트 인증서는 신뢰할 수 있는 루트 개체이므로 대부분의 경우에 작동하지만 애플리케이션에서 인증서 체인을 수락하지 않는 경우 실패할 수 있습니다.

대부분의 경우에 작동한다. 물론 2015-2019 인증서가 교차로 작동할거라 생각하진 않으나 혹시나 하는 생각에 진행해 본다.

tmi로

유지관리 기간 설정은 같은 페이지에서 할 수 있다. 즉시 적용을 하지 않을 계획이라면 알아두자. 필자는 즉시적용을 했다.

재부팅이 이어지고 완료가 되면 접속테스트를 진행한다.

CA-2019 인지라 rds-ca-2015-ap-northeast-2.pem 인증서론 접근이 안된다.

이후 사용한 인증서는 아래의 링크이다. 접속이 잘된다.

https://s3.amazonaws.com/rds-downloads/rds-ca-2019-ap-northeast-2.pem

HeidiSQL 프로그램으로 SSL을 사용한 접근을 하는 테스트를 진행해 보았다.

이테스트를 진행한 이유는 사실 목적은 읽기전용복제본에 있었다.

CA인증서가 변경되면서 master - slave 사이의 통신채널에도 문제가 있을까? 하는 질문을 받았기 떄문이다.

https://aws.amazon.com/ko/rds/details/read-replicas/

보안을 고려한 설계
Amazon RDS for MySQL, Amazon RDS for MariaDB 및 Amazon RDS for PostgreSQL의 읽기 전용 복제본을 생성할 때, Amazon RDS는 리전 간에 복제하더라도 원본 DB 인스턴스와 읽기 전용 복제본 간에 퍼블릭 키 암호화를 사용하여 안전한 통신 채널을 설정합니다. Amazon RDS는 안전한 채널을 제공하는 데 필요한 모든 AWS 보안 구성(예: 보안 그룹 항목을 추가)을 설정합니다.

퍼블릭키 암호화 부분이 CA를 사용하는건 아닐까하는 궁금증이었는데,

스크린샷을 찍어가며 작업한것은 아니나, CA-2015 에서 생성한 읽기전용복제본의 인증기관을 2015 로 설정하고 마스터는 CA-2019 로 변경시에 퍼블릭키를 이용한 암호화 채널에는 아무 문제가 없었다.

고로 퍼블릭 키는 별도의 퍼블릭키라 결론을 내렸다.

현재 CA-2015 에서 CA-2019로 교체이슈가 뜨겁다.

즉시적용이던 유지관리에 적용이던 얼른적용하자.
사실 RDS에서 SSL 인증을 사용하는것이 아니면 기능상의 문제는 없으나....

이벤트에 의해 강제로 리부팅되고 단절에의해 서비스에 장애가 생기는거 보단 미리하는것이 나을것이라 생각한다.

한섭님의 좋은 궁금증이었다.

한섭님께 감사를 드린다!

2019년 10월 18일 by AWS 1

centos8 rdate의 행방

지금까지 rdate로 시간동기화를 강제로 맞췄다.

ntp를 써도 됬지만 centos5에서 적응한 방식이라 레거시에서 벗어날수 없었다.

ansible 테스트중에 알게됬다.

rdate 가 설치되지 않았다.

TASK [rdate] *
fatal: [13.125.94.121]: FAILED! => {"changed": false, "failures": ["rdate 일치하는 패키지 없음"], "msg": "Failed to install some of the specified packages", "rc": 1, "results": []}
…ignoring

centos8 은 4점대 커널이다. centos7은 3점대고.

이커널 차이에서 오는 가장 큰차이점은 ntp 가 기본이냐, chronyd가 기본이냐다.

centos8 부턴 chronyd 기본지원이므로 이전과 같이 불편하게 설정하지 않아도 될것같다.

[root@ip-172-31-45-50] ~# uname -a
Linux ip-172-31-45-50.ap-northeast-2.compute.internal 4.18.0-80.7.1.el8_0.x86_64 #1 SMP Sat Aug 3 15:14:00 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[root@ip-172-31-45-50] ~# rpm -qa | grep chronyd
[root@ip-172-31-45-50] ~# rpm -qa | grep chrony
chrony-3.3-3.el8.x86_64

2019년 10월 7일 by Linux 2

ansible role file module error

ansible 테스트중에 지속적으로 file 모듈에서 에러가 발생했다.

SSH password:

ERROR! 'file' is not a valid attribute for a Play
The error appears to be in '/etc/ansible/roles/locale.yml': line 9, column 3, but may
be elsewhere in the file depending on the exact syntax problem.
The offending line appears to be:
-
file:
^ here

---
become: true
become_user: root
hosts: all
name: rdate
tasks: ~
file:
group: users
mode: 493
owner: tomcatadm
path: /opt/oracle
state: present
name: "create a directory for apache tomcat"

yml 형식도 ok 그런데 file 모듈에서 에러가 발생한다.
그냥 권한 바꾸는 간단한 건데 여기에서 오랫동안 막혀있었다.

# ansible all -m file -a 'dest=/home/test state=file mode=755' -k

SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python"
},
"changed": false,
"gid": 1000,
"group": "centos",
"mode": "0755",
"owner": "centos",
"path": "/home/test",
"size": 0,
"state": "file",
"uid": 1000
}

file 모듈 문제일까 싶어서 ansible 명령어로 테스트 해보니 정상. 왜지?

그냥 배열 정리 잘해주니까 된다..

빡치네..

---
become: true
become_user: root
hosts: all
name: rdate
tasks:
- name: test
file:
mode: 766
path: /home/test
state: file

2019년 10월 5일 by Linux 0

modsecurity-2.9.3 컴파일 에러

centos7 / apache 2.4.36 / mod_security 에러 발생시 해결.

https://forum.directadmin.com/showthread.php?t=56837

In file included from modsecurity.h:49:0,
from apache2_config.c:17:
msc_remote_rules.h:54:9: error: unknown type name 'apr_crypto_key_t'
apr_crypto_key_t **apr_key,
msc_remote_rules.h:55:9: error: unknown type name 'apr_crypto_t'
apr_crypto_t *f,
make[2]: *** [mod_security2_la-apache2_config.lo] Error 1
make[2]: Leaving directory /usr/local/src/modsecurity-2.9.3/apache2′
make[1]: *** [all] Error 2
make[1]: Leaving directory /usr/local/src/modsecurity-2.9.3/apache2'
make: *** [all-recursive] Error 1

처음에 진행한 config

#  ./configure --with-apxs=/usr/local/apache/bin/apxs

apr 관련 에러가 발생한다.

이경우엔 apache 에서 사용하는 apr 이 apr_crypto_key_t 를 지원하지 않는것이다. 라고 생각했는데 아니었다 apr이 지정안되서 그냥 안되는거였다.

#./apachectl -V
Server version: Apache/2.2.34 (Unix)
Server built: Dec 6 2018 13:55:09
Server's Module Magic Number: 20051115:43
Server loaded: APR 1.5.2, APR-Util 1.5.4
Compiled using: APR 1.5.2, APR-Util 1.5.4

사실 그냥하면 될줄알았는데 아니더라...그래서 명시를 해준다.

# ./configure --with-apxs=/usr/local/apache/bin/apxs --with-apr=/usr/local/apache/bin/apr-1-config --with-apu=/usr/local/apache/bin/apu-1-config

잘되었다.

;;

허무하네

/usr/local/modsecurity
[root@localhost modsecurity]# ll
합계 0
drwxr-xr-x 2 root root 70 10월 4 16:11 bin
drwxr-xr-x 2 root root 30 10월 4 16:11 lib

#ll /usr/local/modsecurity/lib/mod_security2.so
-rwxr-xr-x 1 root root 2490512 10월 4 16:11 /usr/local/modsecurity/lib/mod_security2.so

잘된다.

2019년 10월 4일 by Linux 0