작은 거인의 블로그

SSL Termination이란 무엇인가?

`작은거인` — Sat, 7 Aug 2021 18:33:38 +0900

SSL Termination은 데이터 트래픽이 암호화 및 암호화되지 않을 때의 전환 프로세스를 설명합니다.

SSL(Secure Socket Layer) 연결의 서버 측에서 발생합니다.

SSL Termination이란 무엇인가요?

SSL Termination은 SSL로 암호화된 데이터 트래픽이 해독(또는 오프로드)되는 프로세스 입니다.
SSL (Secure Socket Layer) 연결이 있는 서버는 많은 연결 또는 세션을 동시에 처리할 수 있습니다.
SSL 연결은 인증용 인증서를 사용하여 최종 사용자의 컴퓨터와 웹 서버간에 암호화된 데이터를 주고 받습니다.
SSL Termination은 암호 해독 프로세스의 속도를 높이고 백엔드 서버의 처리 부담을 줄입니다.

SSL Termination는 어떻게 작동하나요?

SSL Termination은 서버가 SSL 세션의 SSL(Secure Socket Layer) 연결에서 데이터를 수신할 때 암호화된 https 트래픽을 가로챕니다. SSL Termination 또는 SSL Offloading은 애플리케이션 서버 대신 로드밸런서의 데이터를 해독하고 확인합니다. 들어오는 연결을 구성할 필요 없이 서버는 웹페이지 로드와 같은 다른 작업의 우선 순위를 지정할 수 있습니다. 그래서 서버 속도를 높이는 데 도움이 됩니다. SSL Termination는 SSL 연결의 끝 또는 종료 지점을 나타냅니다.

SSL Termination 로드 밸런서란 무엇인가요?

암호 해독은 리소스와 CPU를 많이 사용하기 때문에 로드 밸런서에게 SSL을 Termination하는 것이 좋습니다. 로드 밸런서에 암호 해독 부담을 가하면 서버가 애플리케이션 작업에 처리 능력을 사용할 수 있으므로 성능을 향샹시키는데 도움이 됩니다. 또한 SSL 인증서 관리를 단순화 시킵니다.

SSL Termination는 안전한가요?

SSL 연결은 민감한 데이터에 중요합니다. 한 가지 주의할 점은 SSL Termination 후 암호화되지 않은 트래픽이 로드 밸런서와 LAN의 백엔드 서버 간에 전송된다는 점입니다. 그러나 보안을 위해 관리자는 로드 밸런서에서 트래픽을 서버로 보내기 전에 다시 암호화하도록 선택할 수 있습니다.

로드 밸런서에서 SSL Termination은 SSL 트래픽을 해독하는데 필요한 추가 컴퓨팅 주기의 웹 서버를 완화합니다. 로드 밸런서가 웹 서버와 동일한 데이터 센터 내에 있을 때 로드 밸런서에서 Termination 되는 보안 위험이 줄어듭니다. 일부 로드 밸런서는 로드 밸런서와 웹 서버 간에 자체 서명된 SSL을 사용하는 기능도 제공합니다. 이렇게 하면 보안 연결이 제공되지만 더 많은 컴퓨팅 성능이 필요합니다.

SSL Termination의 장점:

서버는 들어오고 나가는 모든 데이터를 암호화하고 해독할 필요가 없습니다. 이것이 워크로드를 줄이고 계산 오버헤드를 줄이는 것입니다.
기업이 서버 속도를 향상시키는 데 도움이 됩니다.
SSL 종료는 사용자의 민감한 정보를 다루지 않는 웹사이트에 매우 효과적인 방법입니다. 예를 들어 블로그, 정보 사이트(예: Wikipedia), 미디어 공유 웹 사이트(예: YouTube, Pexels 등).

SSL Termination의 단점:

로드 밸런서와 서버 간의 트래픽은 암호화되지 않으므로 데이터 절도, 세션 하이재킹 및 중간자(MitM) 공격에 취약합니다. 어떤 면에서 SSL 인증서의 목적은 암호화가 중간 과정에서 손실되기 때문에 파괴됩니다.
서버는 로드 밸런서 도구와 개인 키를 공유해야 합니다. 위험한 습관입니다.
로드 밸런서와 서버 간에 HTTPS 세션이 손상된 경우 클라이언트는 경고를 받지 않습니다. 따라서 어떤 면에서는 웹 사용자가 자신의 데이터가 실제보다 더 안전하다고 믿도록 기만합니다.
모든 데이터가 타사 로드 밸런서 플랫폼에 노출되면 기밀 및 개인 정보 보호 요소가 손실될 수 있습니다.

특정 AWS 계정과 AMI 공유

`작은거인` — Wed, 21 Jul 2021 15:35:26 +0900

AMI를 Public으로 설정하지 않고 지정한 AWS 계정과 Private 하게 공유하여 사용할 수 있습니다.

AMI 공유 작업은 AWS 계정 ID(ex: 12자리 숫자)만 있으면 가능합니다.

암호화되지 않은 볼륨 및 고객 관리형 키(으)로 암호화된 볼륨이 있는 AMI만 공유할 수 있습니다.
AMI는 리전 리소스이기 때문에 AMI를 공유하면 해당 리전에서 사용할 수 있습니다.
AMI를 다른 리전에서 사용할 수 있도록 하려면 AMI를 해당 리전에 공유한 후에 복사 합니다.
- 자세한 내용은 AMI 복사 참고 합니다.
AMI에서 공유할 수 있는 AWS 계정 수에는 제한이 없습니다.

주의할 점

AMI를 암호화된 볼륨과 공유할 경우 AMI의 암호화에 사용되는 모든 고객 관리형 키도 공유해야 합니다.
공유 AMI에 연결하는 사용자 정의 태그는 사용자 AWS 계정에서만 사용할 수 있으며 AMI가 공유되는 다른 계정에서는 사용할 수 없습니다.

`콘솔` AMI 공유

A 계정 https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔 열기
A 계정 AMI 메뉴에서 AMI를 선택 후 작업 → 이미지 권한 수정 선택
A 계정 AWS 계정 번호(공유 할 AWS 계정 ID 12자리)를 지정하고 권한 추가를 합니다.
(AMI를 다수의 사용자와 공유하려면 이 단계를 반복하여 사용자를 추가)

A 계정 스냅샷 볼륨 권한 생성을 허용하려면 체크 박스에서 "권한 생성 시 연결된 스냅샷에 대해 "볼륨 생성" 권한 추가" 를 선택합니다. (선택을 하지 않으면 권한 오류 발생)

AMI를 공유하기 위해서 해당 AMI의 레퍼런스인 Amazon EBS 스냅샷을 함께 공유할 필요는 없습니다. AMI만 공유하면 시스템에서 시작에 필요한 Amazon EBS 스냅샷 액세스를 인스턴스에 자동으로 제공합니다. 그러나 AMI가 참조하는 스냅샷을 암호화하는 데 사용되는 모든 KMS 키을(를) 공유해야 합니다.

A 계정 AMI를 공유하는 AWS 계정 ID를 확인하려면 AMI를 선택하고 권한 탭을 선택합니다.
B 계정 AMI 이미지 목록에서 프라이빗 이미지를 첫 필터로 선택하면 A 계정 에서 공유 받은 이미지를 확인할 수 있습니다.

`CLI` AMI 공유

AWS CLI을 사용하여 다음 예시와 같이 AMI를 공유할 수 있습니다.

AWS 계정에 특정 AMI의 시작 권한을 허용하는 명령어 입니다.

aws ec2 modify-image-attribute \
    --image-id ami-0abcdef1234567890 \
    --launch-permission "Add=[{UserId=123456789012}]"

다음 명령은 스냅샷 볼륨 권한 생성을 허용합니다.

aws ec2 modify-snapshot-attribute \
    --snapshot-id snap-1234567890abcdef0 \
    --attribute createVolumePermission \
    --operation-type add \
    --user-ids 123456789012

모든 시작 권한을 제거하는 방법
다음 명령은 특정 AMI의 퍼블릭 및 명시적 시작 권한을 모두 삭제하는 데 사용됩니다.
```
aws ec2 reset-image-attribute \
    --image-id ami-0abcdef1234567890 \
    --attribute launchPermission
```

`콘솔` AMI 복사

AWSManagement Console, AWS Command Line Interface 또는 SDK나 Amazon EC2 API를 사용하여 AWS 리전 내부 또는 리전에 걸쳐 Amazon Machine Image(AMI)를 복사할 수 있습니다.

B 계정 공유된 AMI 이미지를 AMI 복사를 사용하여 다른 리전에 공유해서 사용하거나 소유자를 변경하여 사용할 수 있습니다.

참고

[AWS] EC2에 CloudWatch Agent 구성하여 로그 중앙 집중화

`작은거인` — Fri, 16 Jul 2021 13:15:18 +0900

Amazon Linux 2에 CloudWatch Agent를 설치하고 구성하여 로그 중앙 집중화하는 방법을 알아보겠습니다.

EC2 인스턴스 로그 수집 및 모니터링
- CloudWatch Logs를 사용하면 로그 데이터를 통해 애플리케이션과 시스템을 모니터링 할 수 있음
- CloudWatch Logs는 모니터링하는데 로그 데이터를 사용하므로 코드를 변경할 필요가 없음
- CloudWatch Logs에서는 애플리케이션 로그에서 발생하는 오류의 수를 추적하고 오류 비율이 지정한 임계값을 초과할 때마다 알림 전송이 가능
CloudWatch Logs 로그 보존
- 기본적으로 로그는 무기한 저장되고 만료 기간은 없음 ( 데이터 보존 기관 설정 가능 )
- CloudWatch Logs를 사용하여 내구성이 뛰어난 스토리지에 로그데이터를 저장
- 필터 패턴을 사용하여 로그 이벤트에서 일치하는 단어, 구문 또는 값을 검색이 가능
CloudWatch Logs 설정 방법
1. EC2 에서 사용할 IAM Role을 생성 및 설정
2. CloudWatch Logs 에이전트 설치 및 설정
3. CloudWatch Logs 에서 수집된 로그 확인

(AWS) EC2 에서 사용할 IAM Role을 생성 및 설정

IAM Role 생성 시 trusted entity를 EC2로 선택하고 CloudWatchAgentServerPolicy를 추가 합니다.

CloudWatchAgentServerPolicy 내용을 살펴보면 아래와 같습니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "cloudwatch:PutMetricData",
                "ec2:DescribeVolumes",
                "ec2:DescribeTags",
                "logs:PutLogEvents",
                "logs:DescribeLogStreams",
                "logs:DescribeLogGroups",
                "logs:CreateLogStream",
                "logs:CreateLogGroup"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ssm:GetParameter"
            ],
            "Resource": "arn:aws:ssm:*:*:parameter/AmazonCloudWatch-*"
        }
    ]
}

EC2 인스턴스를 선택하고 보안 → IAM 역할 수정을 선택하여 위에서 생성한 Role을 연결합니다.

(EC2) CloudWatch Logs 에이전트 설치 및 설정

Agent 구성방식은 AWS 에서 제공하는 Wizard를 사용하는 방법과 구성파일을 수동으로 생성하는 방법이 있습니다. 포스팅에서는 수동으로 구성하는 방법에 대해서 설명하겠습니다.

EC2 CloudWatch Agent RPM 다운로드 합니다.

[ec2-user@ip-10-0-11-111 ~]$ sudo su -
[root@ip-10-0-11-111 ~]# wget https://s3.amazonaws.com/amazoncloudwatch-agent/amazon_linux/amd64/latest/amazon-cloudwatch-agent.rpm;
--2021-07-16 12:00:42--  https://s3.amazonaws.com/amazoncloudwatch-agent/amazon_linux/amd64/latest/amazon-cloudwatch-agent.rpm
Resolving s3.amazonaws.com (s3.amazonaws.com)... 52.216.128.53
Connecting to s3.amazonaws.com (s3.amazonaws.com)|52.216.128.53|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 41427996 (40M) [application/octet-stream]
Saving to: ‘amazon-cloudwatch-agent.rpm’

100%[================================================================================>] 41,427,996  8.49MB/s   in 5.6s

2021-07-16 12:00:49 (7.04 MB/s) - ‘amazon-cloudwatch-agent.rpm’ saved [41427996/41427996]

EC2 CloudWatch Agent RPM 설치 & 확인 합니다.

[root@ip-10-0-11-111~]# rpm -Uvh amazon-cloudwatch-agent.rpm;
Preparing...                          ################################# [100%]
create group cwagent, result: 0
create user cwagent, result: 0
Updating / installing...
   1:amazon-cloudwatch-agent-1.247348.################################# [100%]

[root@ip-10-0-11-229 nginx]# rpm -qa | grep amazon-cloudwatch-agent
amazon-cloudwatch-agent-1.247348.0b251302-1.x86_64

EC2 Heredoc 문법을 사용하여 config.json 파일에 설정 파일을 만듭니다.

cat <<EOF > /opt/aws/amazon-cloudwatch-agent/bin/config.json
{
    "agent": {
        "metrics_collection_interval": 30,
        "run_as_user": "root"
    },
    "logs": {
        "logs_collected": {
            "files": {
                "collect_list": [
                    {
                        "file_path": "/var/log/nginx/access.log",
                        "log_group_name": "WEB_LogGroup",
                        "log_stream_name": "[WEB] {instance_id} (access.log)"
                    },
                    {
                        "file_path": "/var/log/nginx/error.log",
                        "log_group_name": "WEB_LogGroup",
                        "log_stream_name": "[WEB] {instance_id} (error.log)"
                    }
                ]
            }
        }
    }
}
EOF

EC2 CloudWatch 에이전트를 시작합니다.

[root@ip-10-0-11-111 nginx]# /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json;
****** processing amazon-cloudwatch-agent ******
/opt/aws/amazon-cloudwatch-agent/bin/config-downloader --output-dir /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d --download-source file:/opt/aws/amazon-cloudwatch-agent/bin/config.json --mode ec2 --config /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml --multi-config default
Successfully fetched the config and saved in /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/file_config.json.tmp
Start configuration validation...
/opt/aws/amazon-cloudwatch-agent/bin/config-translator --input /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json --input-dir /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d --output /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml --mode ec2 --config /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml --multi-config default
2021/07/16 12:08:13 Reading json config file path: /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/file_config.json.tmp ...
Valid Json input schema.
I! Detecting run_as_user...
No csm configuration found.
No metric configuration found.
Configuration validation first phase succeeded
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent -schematest -config /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml
Configuration validation second phase succeeded
Configuration validation succeeded

****** processing amazon-cloudwatch-agent ******
Redirecting to /bin/systemctl stop amazon-cloudwatch-agent.service

EC2 CloudWatch 에이전트를 잘 동작하는지 확인 해보도록 하겠습니다.

[root@ip-10-0-11-111 nginx]# /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a status;
{
  "status": "running",
  "starttime": "2021-07-16T03:09:07+0000",
  "configstatus": "configured",
  "cwoc_status": "stopped",
  "cwoc_starttime": "",
  "cwoc_configstatus": "not configured",
  "version": "1.247348.0b251302"
}

[root@ip-10-0-11-111 nginx]# ps -ef | grep cloudwatch
root      4308     1  0 12:09 ?        00:00:05 /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent -config /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml -envconfig /opt/aws/amazon-cloudwatch-agent/etc/env-config.json -pidfile /opt/aws/amazon-cloudwatch-agent/var/amazon-cloudwatch-agent.pid
root      4501  3794  0 12:46 pts/1    00:00:00 grep --color=auto cloudwatch

EC2 config.json 구성 파일에서 설정한 값이 어떻게 CloudWatch Logs로 보여줄지 amazon-cloudwatch-agent.toml 파일을 통해서 확인할 수 있습니다.

# cat /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml
[agent]
  collection_jitter = "0s"
  debug = false
  flush_interval = "1s"
  flush_jitter = "0s"
  hostname = ""
  interval = "30s"
  logfile = "/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log"
  logtarget = "lumberjack"
  metric_batch_size = 1000
  metric_buffer_limit = 10000
  omit_hostname = false
  precision = ""
  quiet = false
  round_interval = false

[inputs]

  [[inputs.logfile]]
    destination = "cloudwatchlogs"
    file_state_folder = "/opt/aws/amazon-cloudwatch-agent/logs/state"

    [[inputs.logfile.file_config]]
      file_path = "/var/log/nginx/access.log"
      from_beginning = true
      log_group_name = "WEB_LogGroup"
      log_stream_name = "[WEB] i-012345665656e42fd03 (access.log)"
      pipe = false

    [[inputs.logfile.file_config]]
      file_path = "/var/log/nginx/error.log"
      from_beginning = true
      log_group_name = "WEB_LogGroup"
      log_stream_name = "[WEB] i-012345665656e42fd03 (error.log)"
      pipe = false
    [inputs.logfile.tags]
      metricPath = "logs"

[outputs]

  [[outputs.cloudwatchlogs]]
    force_flush_interval = "5s"
    log_stream_name = "i-012345665656e42fd03"
    region = "ap-northeast-2"
    tagexclude = ["metricPath"]
    [outputs.cloudwatchlogs.tagpass]
      metricPath = ["logs"]

(선택) EC2 편의성을 위해 마법사를 사용하여 에이전트 구성 파일을 생성할 수 있습니다. 나중에 파일을 수동으로 편집하여 지표 또는 로그를 추가하거나 제거할 수 있습니다.
```
$ /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard
...
```

(AWS) CloudWatch Logs 에서 수집된 로그 확인

AWS Cloudwatch Logs에서 정상적으로 로그가 수집되는 것을 보실 수 있습니다.

참고 링크

Terraform 작동 방식 ✨

`작은거인` — Fri, 16 Jul 2021 00:29:56 +0900

Terraform은 인프라를 안전하고 효율적으로 구축, 변경, 관리하기 위한 도구입니다.
Terraform은 논리적으로 Terraform Core 와 Terraform Plugin의 두 가지 주요 부분으로 나뉩니다 .

Terraform Core는 RPC(원격 프로시저 호출)를 사용하여 Terraform Plugin과 통신하고 사용할 플러그인을 검색하고 로드하는 다양한 방법을 제공합니다.

Terraform 플러그인의 중요성과 확장성을 모두 이해하려면 Terraform의 아키텍처를 이해하는 것이 중요합니다.

Terraform Core

Terraform Core는 Go 프로그래밍 언어로 작성된 정적으로 컴파일된 바이너리입니다. 컴파일된 바이너리는 Terraform을 사용하는 모든 사람을 위한 진입점인 명령줄 도구(CLI) 입니다.

Terraform Core는 구성을 읽고 종속성 그래프를 작성하는 역할을 합니다.

Terraform Core의 역할

코드로서의 인프라: 구성 파일 및 모듈 읽기 및 보간
리소스 상태 관리
리소스 그래프 구성
계획 실행
RPC를 통한 플러그인과의 통신

Terraform Plugin

Terraform 플러그인 은 외부 단일 정적 바이너리입니다. Plan 및 Apply 단계에서 Terraform Core는 RPC 인터페이스를 통해 이러한 Terraform 플러그인과 통신 합니다.

Terraform Provider 플러그인은 타사 서비스와 통신하기 위한 기본 CRUD (생성, 읽기, 업데이트 및 삭제) API를 사용하여 리소스를 구현합니다.

Terraform Provider Plugins 역할

API 호출에 사용되는 포함된 라이브러리의 초기화
인프라 제공자를 통한 인증
특정 서비스에 매핑되는 리소스 정의Terraform Provisioner Plugins 역할
생성 후 또는 파괴 시 지정된 리소스에서 명령 또는 스크립트를 실행합니다.

Upstream APIs

Upstream API는 Terraform이 상호 작용하는 타사, 외부 서비스 또는 API입니다.
Terraform Core는 이러한 API와 직접 상호 작용하지 않습니다. 대신 Terraform Core는 Terraform Provider에 작업을 수행하도록 요청하고 플러그인은 업스트림 API와 통신합니다.
Terraform Core는 API 뉘앙스에 대해 알 필요가 없고 Terraform Provider Plugins는 그래프 이론에 대해 알 필요가 없습니다.

정리하면, Terraform Provier 플러그인 자체는 기본 CRUD 작업에 대해서만 업스트림 API를 호출한다는 점에 유의 하는 것이 중요하다. Terraform 구성 로딩, 그래프 등과 관련된 어떤 것도 전혀 알지 못합니다. Terraform 플러그인 제공자와 Terraform Core 간의 분리 때문에 , 제공자에게 필요한 작업은 더 간단하며 클라이언트 라이브러리의 추상화일 뿐입니다.

Terraform 오류

앞에서 Terraform 작동 방식에 대해서 알아보았습니다.
Terraform 아키텍처를 이해함으로써 어떤 포인트에서 에러가 발생했는지 조기에 발견 하여 신속한 조치가 가능합니다. 추가로 Terraform에서 발생할 수 있는 오류에 대해 살펴 보도록 하겠습니다.

Terraform에서 발생할 수있는 잠재적인 문제 유형에는 언어, 상태, 핵심, 공급자 오류의 4가지가 있습니다.

Terraform troubleshooting model

Terraform troubleshooting model

Language Error :

Terraform의 기본 인터페이스는 선언적 구성 언어 인 HCL (HashiCorp 구성 언어)입니다.
Terraform 핵심 애플리케이션은 구성 언어를 해석합니다.
Terraform이 구성에서 구문 오류를 발견하면 줄 번호와 오류 설명을 출력합니다.

2. State Error :

Terraform 상태 파일은 프로비저닝 된 리소스에 대한 정보를 저장합니다.
리소스를 구성에 매핑하고 모든 관련 메타 데이터를 추적합니다.
상태가 동기화되지 않은 경우 Terraform은 기존 리소스를 파괴하거나 변경할 수 있습니다.
리소스를 새로 고치거나 가져 오거나 교체하여 구성이 동기화되었는지 확인합니다.

3. Core Error :

Terraform 핵심 애플리케이션에는 작업에 대한 모든 논리가 포함되어 있습니다.
구성을 해석하고, 상태 파일을 관리하고, 리소스 종속성 그래프를 구성하고, 공급자 플러그인과 통신합니다.
이 수준에서 생성 된 오류는 버그 일 수 있습니다.

4. Provider Error :

공급자 플러그인은 인증, API 호출 및 서비스에 대한 리소스 매핑을 처리합니다.

Reference

How Terraform Works : https://www.terraform.io/docs/extend/how-terraform-works.html

[IaC] Terraform 모범 사례 & 컨벤션

`작은거인` — Fri, 11 Jun 2021 22:14:59 +0900

테라폼 문서

✨ 문서화 모범 사례

테라폼 코드는 그 자체로 문서의 한 형태입니다. 간단한 언어로 배포한 인프라와 인프라 구성 방법을 정확하게 설명하고 있으나 자체 문서화 코드는 없습니다.

잘 쓰인 코드는 어떤 기능을 하는지 잘 알려주지만, 왜 그렇게 하는지 설명하지 않습니다. 그렇기 때문에 IaC를 포함한 모든 소프트웨어가 코드 자체를 넘어서는 문서가 필요합니다.

정의된 문서

github VPC Module 저장소의 README.md 문서를 참고하세요.

정의된 문서(README)를 사용해야 하는 이유

테라폼 모듈에는 용도, 사용 이유, 사용 및 수정 방법을 설명하는 Readme가 있어야 합니다.

테라폼 코드 작성보다 먼저 Readme를 작성하는 것이 좋습니다.

RDD (Readme Driven Development)
코드 작성을 고려하기 전에 무엇을 빌드할지 이유를 고려해야 합니다.
작성하는 데 약간에 시간이 걸리더라도 나중에 코드 작성 시간을 줄이고 오류를 최소하고 코드 작성 시간을 절약할 수 있다.

Readme 의 기본 정보 외에도 튜토리얼, API 문서, 위키 페이지 및 코드가 어떻게 동작하는지, 왜 이렇게 작성되었는지에 대한 설명하는 디자인 문서가 필요합니다.

코드화된 문서

github VPC Module 저장소의 main.tf 파일을 참고하세요
github VPC Module 저장소의 variables.tf 파일을 참고하세요

코드화된 문서를 사용하자

######
# VPC
######
resource "aws_vpc" "this" {
  count = var.create_vpc ? 1 : 0
...
}
###################
# DHCP Options Set
###################
resource "aws_vpc_dhcp_options" "this" {
  count = var.create_vpc && var.enable_dhcp_options ? 1 : 0
...
}

코드 자체 내에서 주석을 문서 형식으로 사용합니다.

테라폼은 해시(#)로 시작하는 모든 텍스트를 주석 처리 합니다.

코드의 사용 방법이나 코드가 특정 디자인 선택을 사용하는 이유와 같이 코드에서 표현할 수 없는 정보를 제공하는 주석만 포함 합니다.

코드가 하는 일을 설명하기 위해 주석(#)을 사용하면 안됩니다.

테라폼을 사용하면 모든 입력 변수(Input variable) 설명 매개변수를 선언할 수 있으며, 설명 매개변수는 변수의 사용 방법을 설명합니다.

variable "create_vpc" {
  description = "Controls if VPC should be created (it affects almost all resources)"
  type = bool
  default = true
}

테라폼 언어는 주석에 대해 세 가지 다른 구문을 지원합니다.

# 한 줄 주석을 시작하고 줄 끝에서 끝납니다.
// 또한 한 줄 주석을 시작합니다.
/* 시작하고 */ 끝으로 여러 줄 이상에 걸쳐 수 있는 코멘트에 대한 최종 구분 기호입니다.

#한 줄 주석 스타일은 기본 주석 스타일이며 대부분의 경우에 사용한다. 자동 구성 서식 도구는 이중 슬래시 스타일이 관용적이지 않기 때문에 //주석을 #주석 으로 자동 변환 할 수 있습니다 .

예제 코드

github VPC Module 저장소의 example 디렉토리를 참고하세요.
github My Module 저장소의 exmaple 디렉토리를 참고하세요.

예제 코드 사용

테라폼 모듈을 개발할 때 해당 모듈의 사용 방법을 보여주는 예제 코드를 만들 수 있습니다.

올바른 사용법 패턴을 강조하는 훌륭한 방법이자 사용자가 코드를 작성하지 않고도 모듈을 사용하는 방법입니다.

예제 코드를 통해 자동화된 테스트를 추가하기에도 좋습니다.

테라폼 스타일

✨ Terraform 스타일 규칙

Terraform 파서는 구성 파일에 요소를 배치하는 방법에 약간의 유연성을 허용하지만 Terraform 언어에는 사용자가 서로 다른 팀에서 작성한 파일과 모듈 간의 일관성을 위해 항상 따르도록 권장하는 관용적 스타일 규칙도 있습니다. 자동 소스 코드 서식 도구는 이러한 규칙을 자동으로 적용 할 수 있습니다.

각 중첩 수준에 대해 두 개의 공백을 들여 씁니다.
한 줄 값이 있는 여러 인수가 동일한 중첩 수준에서 연속 줄에 나타날 경우 등호(=)를 정렬합니다.

ami = "abc123"
instance_type = "t2.micro"

인수와 블록이 모두 블록 본문 안에 함께 나타나면 모든 인수를 맨 위에 함께 배치 한 다음 그 아래에 중첩 된 블록을 배치합니다. 하나의 빈 행을 사용하여 블록에서 인수를 분리하십시오.
블록 내에서 인수의 논리 그룹을 구분하려면 빈 줄을 사용하십시오.
인수와 “meta-arguments”를 모두 포함하는 블록의 경우 먼저 메타 인수를 나열하고 하나의 빈 줄로 다른 인수와 구분합니다.
메타 인수 블록을 마지막에 놓고 하나의 빈 줄로 다른 블록과 분리합니다.

resource "aws_instance" "example" {
  count = 2 # meta-argument first  
  ami           = "abc123"   
  instance_type = "t2.micro"    
  network_interface {
    # ...   
  }
  lifecycle { # meta-argument block last
    create_before_destroy = true
  }
}

최상위 블록은 항상 하나의 빈 줄로 서로 분리되어야 합니다.
중첩 된 블록은 동일한 유형의 관련 블록을 함께 그룹화하는 경우를 제외하고는 빈 줄로도 구분되어야 합니다 (예 provisioner: 리소스의 여러 블록).
블록 유형이 의미론으로 정의되어 패밀리를 형성하지 않는 한, 동일한 유형의 여러 블록을 다른 유형의 다른 블록과 분리하지 않아야 합니다. (예 : root_block_device, ebs_block_device및 ephemeral_block_deviceon aws_instance은 AWS 블록 디바이스를 설명하는 블록 유형 패밀리를 형성하므로 함께 그룹화하고 혼합 할 수 있습니다.)

테라폼 모듈

✨ 모듈 모범 사례

Terraform 모듈은 대부분의 프로그래밍 언어에서 볼 수 있는 라이브러리, 패키지 또는 모듈의 개념과 유사하며 동일한 이점 제공합니다.

테라폼 모범 사례

Terraform 실무자는 다음 모범 사례에 따라 모듈을 사용

모듈을 염두하고 HCL을 작성

한 사람이 관리하는 적당히 복잡한 Terraform 구성의 경우에도 모듈을 올바르게 사용하는 데 걸리는 시간보다 모듈 사용의 이점이 더 큽니다.

로컬 모듈을 사용하여 코드를 구성하고 캡슐화

원격 모듈을 사용하거나 게시하지 않더라도 처음부터 모듈 측면에서 HCL을 구성하면 인프라가 복잡해짐에 따라 구성을 유지 관리하고 업데이트하는 부담이 크게 줄어 듭니다.

공용 Terraform 레지스트리를 사용하여 유용한 모듈을 검색

이렇게 하면 다른 사람의 작업에 의존하여 공통 인프라 시나리오를 구현함으로써 보다 빠르고 확실하게 구성을 구현할 수 있습니다.

모듈을 게시하고 공유

대부분의 인프라는 팀원에 의해 관리되며 모듈은 팀이 인프라를 만들고 유지 관리하기 위해 협력 할 수 있는 중요한 방법입니다. 앞서 언급했듯이 모듈을 공개 또는 비공개로 게시 할 수 있습니다.

✨ 모듈 개발 (권장 패턴)

사전 구축 된 HCL을 사용하는 테라폼 사용자의 도입 속도를 높이고 진입 장벽을 낮춥니다.

가능한 명확한 구성 및 DRY ( “Don’t Repeat Yourself”) 원칙과 같은 코딩 모범 사례를 사용합니다.

모듈 생성 워크 플로우

새 모듈을 만드는 첫 단계는 얼리 어답터(early adopter)팀 ‍ ‍ 을 찾고 요구 사항을 수집하는 일입니다.

얼리 어답터(early adopter)팀 ‍ ‍ 과 협력하면 좋은점

충분히 유연하게 모듈 기능을 연마할 수 있습니다.

최소한의 코드 변경으로 유사한 요구 사항 신속 처리합니다.

코드 중복이 제거되고 출시 시간을 단축 시킵니다.

요구 사항을 적절한 모듈로 범위 지정

모듈은 한 가지를 잘 수행하도록 독립적으로 설계하고, 처음에 모듈의 범위를 지정할 때 작고 간단한 시작을 목표로 합시다.

모듈을 만들 때 고려 할 사항

캡슐화 : 항상 함께 배포되는 그룹 인프라

모듈에 더 많은 인프라을 포함시키면 사용자가 좀 더 쉽게 배포 할 수 있지만 모듈의 목적과 요구 사항을 이해하기가 어려워집니다.

권한 : 모듈을 권한 경계로 제한

모듈의 인프라가 둘 이상의 그룹의 책임인 경우 해당 모듈을 사용하면 실수로 업무 분리를 위반할 수 있습니다. 권한 경계 내의 리소스만 그룹화하여 인프라 분리해서 인프라를 보호 해야 합니다.

변동성 : 수명이 긴 인프라와 수명이 짧은 인프라 분리

예를 들어, DB 인프라는 비교적 정적이지만 APP서버는 하루에도 여러 번 배포할 수가 있습니다. APP서버와 동일한 모듈에서 DB 인프라를 관리하면 불필요한 변동과 위험에 노출됩니다.

모듈 MVP 만들기

모든 코드와 마찬가지로 모듈은 완전하지 않고, 항상 새로운 모듈 요구 사항과 변경 사항이 있습니다. 이를 수용하고 최소 실행 가능한 제품 (MVP) 표준을 충족하는 처음 몇 가지 모듈 버전을 목표로 합니다.

모듈을 만들 때 고려 할 사항

항상 사용 사례의 80% 이상에서 작동하는 모듈을 제공하는 것을 목표로 합니다.

모듈은 가장 일반적으로 수정되는 인수만 변수로 노출하고, 처음에 모듈은 가장 필요할 가능성이 높은 변수만 사용합니다.

현재 사용하고 있지 않더라도 모듈 MVP에서 가능한 한 많은 정보를 출력합니다.

모듈의 출력을 다음 모듈의 입력으로 사용하여 여러 모듈을 자주 사용하는 최종 사용자에게 모듈이 더 유용합니다.

MVP 범위 지정 살펴보기 (예제)

팀은 Terraform을 사용하여 인프라, 웹 계층 애플리케이션 및 앱 계층 애플리케이션을 프로비저닝하려고합니다. 이를 수용하고 최소 실행 가능한 제품 (MVP) 표준을 충족하는 처음 몇 가지 모듈 버전을 목표로 합니다.

네트워크 모듈

네트워크 모듈은 인프라의 네트워킹을 담당합니다. 여기에는 VPC, Subnet, Routing Table, NAT G/W를 포함하는데, 필요한 경우 NACL 및 Peering 등을 포함할 수 있습니다.

네트워크 모듈에는 높은 권한 과 낮은 변동성이 있기 때문에 이러한 리소스가 포함됩니다.

네트워크 리소스를 만들거나 수정할 권한이 있는 구성원만이 모듈을 사용할 수 있어야 합니다.
이 모듈의 리소스는 자주 변경되지 않기 때문에 자체 모듈로 그룹화하면 불필요한 위험으로부터 보호됩니다.

웹 애플리케이션 모듈

웹 모듈은 웹 애플리케이션을 실행하는 데 필요한 인프라를 생성하고 관리합니다. 여기에는 로드 밸런서 및 오토스켈링 그룹이 포함됩니다. 또한 EC2 인스턴스, 애플리케이션 내부 보안 그룹 및 로깅이 포함될 수 있습니다

웹 모듈에는 캡슐화 되고 변동성 이 높기 때문에 이러한 리소스가 포함됩니다.

이 모듈의 리소스는 범위가 엄격하고 특히 웹 애플리케이션과 연결되어 있습니다. 웹 애플리케이션 구성원이 쉽게 배포 할 수 있도록 단일 모듈로 그룹화 합니다.
모듈의 리소스는 코드 릴리스마다 자주 변경 됩니다. 자체 모듈로 분리하면 불필요한 변동과 다른 모듈에 대한 위험을 줄일 수 있습니다.

데이터베이스 모듈

데이터베이스 모듈은 데이터베이스를 실행하는 데 필요한 인프라를 생성하고 관리합니다. 여기에는 애플리케이션에서 참조하는 RDS 인스턴스가 포함됩니다. 또한 모든 관련 스토리지, 모든 백업 데이터 및 로깅을 포함 할 수 있습니다.

데이터베이스 모듈에는 리소스가 높은 권한 을 갖고 변동성 이 낮기 때문에 이러한 리소스가 포함됩니다.

데이터베이스 리소스를 만들거나 수정할 권한이 있는 구성원만이 모듈을 사용할 수 있어야 합니다.
팀은 이 모듈의 리소스를 자주 변경하지 않을 것이므로 별도의 모듈로 만들면 불필요한 이탈과 위험이 줄어 듭니다.

일관된 모듈 구조 정의 및 사용

모듈 구조는 취향의 문제이지만 모듈 구조를 문서화하고 모든 모듈의 일관성을 유지해야 합니다.

모듈 구조를 일관되게 유지하려면

모듈에 있어야 하는 .tf 파일 목록과 포함 해야 하는 내용을 정의 합니다.

모듈에 대해 .gitignore 정의 합니다.

# Local .terraform directories
**/.terraform/*
# .tfstate files
*.tfstate
*.tfstate.*

변수의 예를 제공하는 표준 방법을 만듭니다. (예 : terraform.tfvars.example)

비어있는 경우에도 정의 된 디렉토리 세트와 함께 일관된 디렉토리 구조를 사용합니다.

모든 모듈 디렉토리에는 그 README안에 있는 파일의 용도와 사용에 대한 세부 정보를 작성합니다.

소스 제어를 사용하여 모듈 추적

Terraform 모듈은 모든 좋은 코드 사례를 준수해야 합니다.

Terraform 모듈은 모든 좋은 코드 사례를 준수

소스 제어에 모듈을 배치하여 릴리스 버전, 협업 및 변경 추적 감사를 관리합니다.

마스터에 모든 릴리스에 태그 및 문서화 (CHANGELOG, README 사용)

마스터에 대한 모든 변경 사항을 코드 검토합니다.

모듈 사용자가 태그로 참조하도록 권장합니다.

# ref인수의 값은 git checkout분기 및 태그 이름을 포함 하여 명령에서 허용되는 모든 참조
module "vpc" {
  source = "git::<https://example.com/vpc.git?ref=v1.2.0>"
}

각 모듈에 소유자를 지정합니다.

저장소 당 하나의 모듈만 사용합니다.

모듈이 멱등성을 유지하고 라이브러리로 작동하는데 중요합니다.
태그가 지정된 릴리스는 비공개 모듈 레지스트리에 대한 요구 사항

코드로서의 협업 인프라

collaborative infrastructure as code

조직 내의 사용자들이 Terraform으로 인프라스트럭처를 안전하게 프로비저닝 할 수 있고 이때 충돌이 발생하지 않으며 접근 권한을 명확하게 이해할 수 있습니다.
조직 내의 전문가가 표준화된 인프라스트럭처 템플릿을 만들 수 있고 초심자는 조직의 인프라스트럭처 권장 사용사례를 따르기 위해 이 템플릿을 사용할 수 있습니다.
워크스페이스의 접근제어로 워크스페이스의 커미터와 승인자가 프로덕션 환경을 보호할 수 있다.
Terraform을 직접 작성하지 않는 기능 그룹은 인프라스트럭처의 상태를 볼 수 있고 Terraform Enterprise의 UI로 변경할 수 있다.

Terraform Cloud & Enterprise 워크플로우

모듈을 생성하여 조직이 바라는 검증되고 안전하고 표준화된 인프라를 효율적으로 프로비저닝 합니다.

코드로 재사용 가능한 템플릿 인프라

필요에 따라 가변적 값 정의

Producer ‍ 는 워크스페이스를 기반으로 모듈을 생성

모듈의 레지스트리에 등록하여 탐색 가능하도록 작업

Cunsumer ‍ 는 레지스트리를 활용하여 애플리케이션에 필요한 인프라 생성

[AWS] Auto Scaling Group 항목 설명

`작은거인` — Thu, 23 Apr 2020 10:10:57 +0900

ㅁ Auto Scaling Group 각 항목에 대한 설명

[AWS] Certificate Manager 인증서 등록

`작은거인` — Thu, 16 Apr 2020 18:06:45 +0900

1. AWS 서비스에서 Certificate Manager 서비스를 검색

2. 시작 화면에서 [인증서 프로비저닝]에서 시작하기 버튼 클릭

3. 기존에 다른 업체에서 발급받은 인증서가 있다면 Certificate Manager에 등록할 수도 있고, 도메인만 발급받은 상태라면 무료로 발급받을 수 있음

4. 구매한 도메인 인증서를 새로 발급받기 위해 [공인 인증서 요청]을 선택하고 [인증서 요청] 버튼을 클릭

5. 인증서 발급받을 도메인을 입력한 뒤 [다음] 버튼을 클릭

서브 도메인까지 포함하는 인증서를 발급받고 싶으면 *.test.com과 같이 와일드카드를 입력

6. 도메인 소유주임을 확인하기 위해 검증 방법으로 두 가지를 제공

DNS 검증 : DNS에 Certificate Manager에서 제시하는 특정 레코드를 추가해서 본인 검증
이메일 검증 : 도메인 관리자 메일 계정으로 이메일을 보내서 본인 검증

7. 태그 추가 후에 요청 내용을 검토하고 문제가 없다면 [확인 및 요청] 클릭

8. 도메인에 다음과 같이 CNAME 기록을 추가하라는 화면을 보여줌

AWS가 아닌 외부 업체를 통해 업체 사이트에서 레코드를 추가
AWS Route 53을 통해 등록한 경우는 하단의 [Route 53에서 레코드 생성] 버튼을 클릭하면 자동으로 레코드가 생성

9. 레코드를 성공적으로 등록하면 최대 30분 내 AWS에서 레코드가 등록된 것을 확인하고 신청한 인증서의 상태를 [발급 완료]로 변경해서 표시

10. 발급한 인증서를 ELB에 등록하기 위해 EC2 서비스 [로드 밸런싱] → [로드밸런서] 이동하고 HTTPS 프로토콜 리스터를 추가하기 위해 추가 버튼 클릭

11. 프로토콜은 HTTPS로 선택하고 [전달 대상]은 대상 그룹 (Target Group)을 지정하고 SSL 인증서는 앞에서 추가한 인증서를 선택

12. EC2 서비스의 [로드 밸런싱] → [로드 밸런서] 메뉴에서 [리스터] 탭을 보면 HTTPS 프로토콜에 대한 리스너, SSL 인증서가 추가된 것을 확인

13. 도메인 주소에서 https로 다시 접속을 해보면 정상으로 연결된 것을 확인

[AWS] 탄력적 IP (Elastic IP) 설명

`작은거인` — Thu, 16 Apr 2020 14:53:28 +0900

탄력적 IP (Elastic IP) 주소란?

탄력적 IP 주소는 동적 클라우드 컴퓨팅을 위해 고안된 고정 퍼블릭 IPv 주소
모든 인스턴스 또는 네트워크 인터페이스에 탄력적 IP 주소를 연결 가능
현재는 IPv6에 대한 탄력적 IP주소를 지원하지 않음

탄력적 IP (Elastic IP)를 사용하는 이유?

EC2 인스턴스를 생성하여 서버를 실행시키면 고정 IP가 아닌 동적 IP를 할당받습니다. 인스턴스(서버)를 중지하고 다시 실행시키면 IP가 변경되어 버리는 문제가 발생합니다. 그렇기 때문에 탄력적 IP를 할당받아서 사용해야 합니다.

탄력적 IP (Elastic IP) 요금에 대한 이해

Amazon 인스턴스를 모두 종료했지만 여전히 탄력적 IP 주소에 대한 요금이 발생되고 있습니다. 이유는 무엇일까요?
해결 방법 (조건)
- 탄력적 IP 주소가 EC2 인스턴스에 연결되어 있는 경우
- 탄력적 IP 주소가 연결된 인스턴스가 실행 중인 경우
- 인스턴스에 연결된 탄력적인 IP 주소가 하나뿐인 경우

사용하지 않는 탄력적 IP의 경우 비용이 발생하므로 사용하지 않는 탄력적 IP는 연결 해제 한 후 릴리스를 통해 제거를 해야 추가 비용이 발생하지 않습니다.

탄력적 IP (Elastic IP) 요금

실행 중인 인스턴스에 연결된 IP 주소 (EIP) 한 개는 무료로 사용
해당 인스턴스에 추가 EIP를 연결하면 인스턴스와 연결된 추가 EIP당 시간에 비례하여 요금 부과
추가 EIP는 Amazone VPC에서만 사용가능
요금 (아시아 태평양 [서울])
- 실행 중인 인스턴스와 연결된 각 추가 IP 주소에 대해 시간당 0.005 USD(비례 할당으로 계산)
- 실행 중인 인스턴스와 연결되지 않은 각 탄력적 IP 주소에 대해 시간당 0.005 USD(비례 할당으로 계산)
- 매달 처음 100개의 재매 핑에 대해 탄력적 IP 주소 재 매핑당 0.00 USD
- 매달 100개 이후 추가 재매핑에 대해 탄력적 IP 주소 재 매핑당 0.10 USD
링크
- https://aws.amazon.com/ko/ec2/pricing/on-demand/#Elastic_IP_Addresses

[CentOS] Nginx서버 http -> https리다이렉트

`작은거인` — Mon, 16 Mar 2020 14:41:51 +0900

http는 웹 서버와 브라우저간에 통신이 이루어지는 프로토콜입니다. SSL (Secure Sockets Layer)과 같은 프로토콜을 사용하여 웹 서버와 브라우저 간의 데이터를 암호화합니다. 따라서 모든 http 데이터를 https 프로토콜로 리다이렉션 하는 것이 좋습니다.

https 리다이렉트 하는 방법

전체조건

Nginx에서 https를 설정
ㅁ 개인키 CSR키를 생성해야 합니다.
키를 생성한 후 인증 기관에서 SSL 인증서를 얻어야 합니다.
SSL 인증서와 키를 추가하여 Nginx 서버 블록을 구성합니다.
Nginx 변경 사항을 저장하고 reload 합니다.

# Redirecting all HTTP traffic to HTTPS

server {
  listen 80 default_server;
  listen [::]:80 default_server;
  return 301 https://$host$request_uri;
}

서버의 모든 호스트 이름을 리다이렉션 하는 매우 일반적인 구성입니다. 코드를 한 줄씩 살펴봅시다.

server
ㅁ 코드가 작성되는 블록의 이름
listen 80 default_server;
ㅁ 포트 번호 80은 http 포트이고, default_server는 서버 호스트 이름입니다.
ㅁ IPv4 HTTP 패킷을 리다이렉션 합니다.
listen [::]:80 default_server;
ㅁ 위와 동일하지만 모든 IPv6 HTTP 트래픽에 대해 작동합니다.
return 301 https://$host$request_uri;
ㅁ Code 301은 트래픽을 리다이렉션 하는 데 사용됩니다.

여기서 "test.com"및 "www.test.com"의 모든 HTTP 트래픽은 HTTPS로 리디렉션 됩니다.

# Here is an example for your reference.

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name test.com www.test.com;
    return 301 https://$server_name$request_uri;
}

[SSH] SFTP 연결이 안되는 경우

`작은거인` — Wed, 11 Mar 2020 12:17:13 +0900

증상:

ㅁ SSH 프로토콜로 서버 간 접속은 문제가 없다.

ㅁ SFTP로 타켓 서버로 연결을 시도할 경우 아래와 같이 연결 실패 오류가 발생하는데, 보통 SSH 연결이 실패할 경우 아래 2가지를 의심할 수 있지만 SSH 연결은 정상이기 때문에 아래 조건은 배제한다.

SSH Key 설정 (authorized_keys)
방화벽 설정 (iptables, firewall, pam... 등)

[root@sg-dist ~]# ssh root@appservice-api-001.test.com -vvv         
Last login: Wed Mar 11 10:22:37 2020 from 1.1.1.1

[root@sg-dist ~]# sftp root@appservice-api-001.test.com -vvv
subsystem request failed on channel 0
Couldn't read packet: Connection reset by peer'

원인:

ㅁ SFTP를 사용을 위해서는 sshd_config 설정에서 아래 라인이 주석처리(비활성화) 되어 있음을 확인했다.

[root@appservice-qa-web-001 ~]# cat /etc/ssh/sshd_config | grep sftp
# Subsystem sftp  /usr/libexec/openssh/sftp-server

해결:

ㅁ sshd_config에서 'Subsystem sftp xxx'라인 주석을 제거(활성화)하고 저장한다.

ㅁ 변경된 sshd 설정 적용을 위해 SSH 데몬을 reload 한다.

ㅁ SFTP 연결을 다시 시도하면 정상적으로 연결된 것을 확인할 수 있다.

sed -i 's/#Subsystem/Subsystem/' /etc/ssh/sshd_config;
systemctl reload sshd

[root@sg-dist ~]# sftp root@appservice-api-001.test.com -vvv
Connected to appservice-api-001.test.com.
sftp> quit