웹사이트 검색

의 자습서에 대한 기술 권장 사항 및 모범 사례


소개

이 가이드는 DigitalOcean 튜토리얼 작성자를 위한 확립된 모범 사례와 강력한 권장 사항을 요약하기 위한 것입니다. 이는 DigitalOcean의 교육 자료에서 일관성, 기술적 정확성 및 사용 편의성을 위한 기반을 제공하기 위한 것입니다.

이 가이드는 본질적으로 진행 중인 작업이자 사내 기술 작가 및 편집자, 커뮤니티 관리자 및 엔지니어의 증가하는 경험을 기반으로 하는 독단적인 문서입니다. 권장 사항은 변경될 수 있으며 광범위한 독자와 최종 사용자를 염두에 두고 교육 콘텐츠용으로 특별히 작성되었습니다.

소프트웨어 소스 및 설치

많은 자습서는 기존 자습서를 전제 조건으로 사용합니다. 깊게 중첩된 전제 조건 목록을 포함하지 않고 문서에 대한 모든 전제 조건(전제 조건에 대한 중첩 전제 조건 포함)을 문서에 넣습니다.

선호하는 출처

대략적인 내림차순으로 다음 설치 메커니즘을 사용하십시오.

  1. 가장 좋다고 평가될 때 프로젝트 권장 방법. 많은 프로젝트가 빠르게 변경되고 공식 리포지토리를 넘어서는 것이 좋습니다. 그러나 일부 설치(예: curl | bash 패턴)는 사용 여부에 대한 판단이 필요합니다.
  2. 현재 배포 및 릴리스의 공식 패키지 저장소.
  3. 언어별 공식 패키지(NPM, CPAN, PIP, RubyGems, Composer 등)
  4. 프로젝트별 패키지 리포지토리(예: Nginx는 최신 버전에 대한 자체 리포지토리 제공) 또는 Ubuntu에서 신뢰할 수 있는 PPA. 프로젝트 개발자 또는 Debian/Ubuntu 패키지 관리자와 같이 신뢰할 수 있는 출처에서 가져온 것인지 확인하세요.
  5. 프로젝트의 GitHub 릴리스 페이지 또는 유사한 공식 웹 소스의 바이너리
  6. wget 또는 curl은 스크립트 검사에 대한 적절한 경고와 함께 셸에 연결된 스크립트를 설치합니다.

선호하는 설치 위치

일반적으로 불필요한 합병증을 피하십시오. 소스 또는 바이너리에서 설치된 패키지되지 않은 소프트웨어의 경우 매우 일반적이지 않거나 충돌이 발생하지 않는 한 일반적으로 기본 설치 접두사를 수락해야 합니다.

패키지나 다른 설치 방법에서 제공하지 않는 경우 배포판에 대한 공식 권장 사항을 준수하는 초기화 스크립트가 서비스 지향 소프트웨어에 제공되어야 합니다.

Linux 시스템에서 자체 포함 바이너리 또는 디렉터리는 /opt에, 독립형 스크립트는 /usr/local/bin에 넣습니다.

소프트웨어 및 시스템 유지보수

Ubuntu 및 Debian 시스템에는 최소한 보안 업데이트가 설치 및 구성된 무인 업그레이드가 있어야 합니다. 상황에 따라 자동 재부팅 또는 자동 업데이트를 사용하지 않는 것이 좋습니다.

일반적으로 Ubuntu 18.04 이상에서는 apt 명령을 사용하는 것이 좋습니다. apt를 사용하도록 apt-getapt-cache를 변경합니다. apt 명령을 업데이트할 때 -y 플래그를 사용하지 마십시오. 독자는 필요한 입력과 프롬프트를 통해 안내를 받아야 합니다.

CentOS 및 Rocky Linux 자습서의 경우 이제 yum을 대체하고 더 나은 성능을 제공하는 dnf를 사용하는 것이 좋습니다.

자습서가 최신 업데이트에 의존하는 경우 1단계 설정 중에 또는 필요에 따라 updateupgrade를 호출합니다. 서버가 패키지의 최신 버전을 가져오도록 먼저 update를 호출합니다. 모든 패키지의 새 버전을 다운로드하고 설치하는 업그레이드를 포함할 때 일부 사용자는 특정 패키지를 더 낮은 버전으로 유지하도록 선택할 수 있습니다.

서비스 관리

레거시 호환성 명령을 사용할 수 있는 경우에도 기본 init 시스템 명령을 사용해야 합니다. 예를 들어, sudo service [service_name] start가 작동하더라도 sudo systemctl start [service_name]를 사용하십시오.

부팅 시부터 서비스를 활성화 또는 비활성화하는 방법에 대한 정보를 제공합니다. 인터페이스(journalctl -u, systemctl status 등)에서 명확하게 표시되지 않는 경우 서비스 관련 명령의 결과를 검사하는 방법을 나타냅니다.

경험상 서비스를 다시 로드하는 것보다 다시 시작하는 것이 좋습니다. 대부분의 경우 서비스 중단을 피하는 것보다 알려진 상태를 확인하는 것이 더 중요하며 전체 서비스 장애가 발생한 경우 다시 시작하는 것이 더 유용합니다.

부트스트래핑 시스템

구성 관리 워크플로의 일부가 아닌 경우 사용자 데이터 스크립트를 선호하고 대부분의 경우 사용자 데이터에서 bash 스크립트보다 cloudinit 스크립트를 선호합니다.

로깅 및 문제 해결

설치된 서비스의 로그에 액세스하는 위치와 방법을 설명하십시오. 해당하는 경우 서비스 상태 및 로그 출력을 확인하기 위한 systemctljournalctl 명령을 설명하십시오. 가능한 경우 일반적인 실패 사례를 진단하기 위한 간결한 제안을 제공합니다.

패키지 또는 기타 설치 메커니즘에서 처리하지 않는 모든 경우에 대해 로그 회전을 처리해야 합니다.

다음 일반 텍스트 로그 파일의 경우 tail -f가 아닌 tail -F를 사용하세요. 사용자가 그들을 보고 있습니다.

사용자 및 그룹 관리

루트를 직접 사용하는 대신 sudo 사용자를 만듭니다. 이 작업을 전제 조건으로 설명하는 적절한 초기 서버 설정 가이드를 참조하십시오.

Debian 기반 배포판에서는 각각 adduser sammydeluser --remove-home sammy를 사용하여 사용자를 추가하고 제거합니다. RHEL 기반 배포에서는 adduser sammy(필요한 경우 passwd sammy로 암호 설정) 및 userdel -r sammy를 사용합니다.

Ubuntu에서 usermod -aG sudo sammysudo 권한을 부여합니다. CentOS는 조금 더 복잡합니다. 최신 버전은 usermod -aG wheel sammy를 사용하지만 일부 버전에서는 먼저 wheel 그룹 권한의 주석을 제거하기 위해 visudo가 필요합니다. 특히 CentOS 5에서는 sudo를 설치해야 하고 휠 그룹의 주석을 visudo로 제거해야 합니다. CentOS 6에서는 sudo가 이미 설치되어 있지만 wheel의 주석을 제거해야 합니다. CentOS 7에는 sudo가 있고 휠 그룹이 이미 설정되어 있습니다.

권한 에스컬레이션된 명령을 사용할 때 작성된 대로 테스트해야 합니다. sudo를 통해 환경 변수를 전달하려면 sudo -E command_to_run(전체 환경에서 신뢰할 수 있는 경우) 또는 sudo FOO=BAR command_to_run을 사용합니다. 루트 셸이 필요한 인스턴스의 경우 sudo -i를 사용합니다. 리디렉션이 필요한 인스턴스의 경우 tee -a를 사용하여 대상 파일을 바꾸지 않고 추가합니다. [sudo] command_to_run | sudo tee [-a] file_to_change.

선호하는 도구

대화형 셸의 경우 관련될 때 명시적으로 언급되는 GNU/Linux 시스템의 Bash를 가정합니다. FreeBSD에서는 즉시 사용할 수 있고 유용한 기능이 있는 tcsh를 사용하십시오.

텍스트 편집기의 경우 "[선호하는] 또는 즐겨찾는 텍스트 편집기 사용\이라는 문구를 포함하고 이러한 복사 및 붙여넣기를 위한 명령에 초보자에게 친숙한 다음 편집기를 포함합니다. Linux에서는 기본적으로 nano 가 사용됩니다. ; FreeBSD에서는 기본적으로 ee를 사용합니다. vi(m)은 허용되지만 초보자에게 걸림돌이 될 수 있는 소개 주제에서는 사용하지 않습니다.

파일 전송의 경우 대부분의 경우 대화식 및 scp와 유사한 용도로 sftp를 권장하지만 푸시 기능이 없기 때문에 scp도 허용됩니다. rsync는 백업 및 대용량 전송(또는 많은 작은 파일)에 유용합니다. 어떤 경우에도 FTP를 사용하지 마십시오. 또한 견고성 때문에 wget보다 curl을 표준화하기 위해 노력합니다. wget의 장점은 대부분 재귀 다운로드(즉, 우리 종류의 콘텐츠에 일반적이지 않은 특수 사용 사례)입니다.

iproute2 유틸리티와 함께 제공되는 시스템에서는 구식으로 간주되는 net-tools 제품군보다 이 유틸리티를 선호합니다. 일반적으로 ss와 같은 iproute2 유틸리티는 다중 인터페이스, IPv6, 새로운 커널 기능 등을 더 잘 지원합니다. 마찬가지로 ip route를 사용해야 합니다. over route, ip addr show over ifconfig 등. 때로는 이전 유틸리티 출력이 기본적으로 약간 더 깨끗하지만 출력 자체는 엣지 케이스도 처리하지 않기 때문에 좀 덜 신뢰할 수 있습니다. 가능한 경우 사용 가능한 플래그를 사용하여 더 자세한 출력을 제어합니다.

스크립팅

시스템 관리 자습서의 맥락에서 일반적으로 긴 사용자 지정 스크립트와 긴 셸 스크립트를 사용하지 마십시오.

저자가 작성한 스크립트(및 기타 리소스)는 게시된 자습서로 돌아가는 링크와 함께 do-community GitHub 계정의 문서별 저장소에 있어야 합니다. 일반적으로 좋은 스크립팅 방법을 따르십시오. 예를 들어, 사용자가 입력해야 하는 변수를 스크립트 상단, 가급적 잘 표시된 섹션에 입력합니다. 사람이 읽을 수 있는 스크립트를 제공하기 위해 필요한 경우 인라인 주석을 제공합니다. 코드에 대한 설명이 주석에만 제공되는 것이 아니라 주석에 표시되는 것보다 더 자세한 설명과 함께 산문 설명도 제공해야 합니다.

bash보다 /bin/sh를 선호하고 이식성 또는 교차 플랫폼 재사용이 우려되는 경우 Bash 관련 기능을 피하십시오. 소규모 작업에는 shell 및 coreutils/표준 Unix 도구를 사용하십시오. 이점이 상당한 경우가 아니면 순전히 접착 언어 작업에 대한 새로운 종속성을 도입하지 마십시오. #!/path/to/interpreter보다 #!/usr/bin/env 인터프리터를 선호하십시오.

일반적으로 반복 작업을 예약하려면 cron을 사용하지만 시스템 타이머도 사용할 수 있습니다.

파일 시스템 위치

가능한 경우 문서 IP 범위 또는 example.com 대신 your_server_ipyour_domain을 사용하세요.

스크립트 또는 데이터를 다운로드할 때 사용자가 쓰기 가능한 디렉토리에 있거나 경로가 명시적으로 지정되어 있는지 확인하십시오. 참조하거나 재사용할 수 있어야 하는 파일의 경우 파일 시스템의 다른 곳(예: /opt 또는 /etc). 폐기 파일의 경우 /tmp를 사용하십시오.

자습서가 특정 디렉터리에 의존하는 경우 명령을 실행하기 전에 판독기를 해당 디렉터리로 라우팅하는 cd 명령을 제공해야 합니다.

웹 서버

기본적으로 구성되지 않은 배포판에는 데비안 스타일 구성 디렉토리를 권장합니다. 항상 구성 변경을 테스트합니다(Apache는 sudo apachectl configtest를 사용하고 Nginx는 sudo nginx -t를 사용합니다).

Apache 또는 Nginx 튜토리얼의 경우 기본 구성 파일을 편집하는 대신 전용 가상 호스트 블록을 사용하십시오. 이 경로는 일반적인 실수를 방지하고 기본 파일을 의도한 폴백 구성으로 유지할 수 있습니다.

보안

시스템 간의 모든 연결을 암호화하고 인증합니다. 사용자가 자격 증명을 보내거나 비공개 데이터를 평문으로 전송하도록 (명시적 또는 암시적으로) 권장하지 마십시오.

특히 암호와 키 자료는 보안되지 않은 연결을 통해 전송되어서는 안 됩니다. 데이터베이스 연결, 로깅, 클러스터 관리 및 기타 서비스는 이상적으로는 항상 암호화되어야 합니다.

웹 기반 제어판은 HTTPS 연결을 통해 제공되어야 하며 TLS/SSL은 지원되는 서비스에 사용해야 합니다. 모든 웹 서버는 HTTPS를 지원해야 합니다(또는 최소한 가능해야 함). certbot 전제 조건을 사용하여 SSL 인증을 제공하십시오. 일반 HTTP와 같은 공개 서비스는 사용자가 여전히 이를 제공하기를 원하거나 필요로 할 수 있으므로 허용되지만 일반적인 경우, 특히 동적 콘텐츠의 경우 권장하지 않습니다. 일반 HTTP 연결을 제공하는 문서의 경우 메모 또는 경고 레이블을 추가하여 일반 HTTP를 권장하지 않고 HTTPS를 권장합니다.

기본 SSH 포트 변경과 같이 모호함이나 연극을 통해 보안에 도움이 되지 않는 관행을 피하십시오. 방화벽을 구성하십시오. 배포판별 권장 사항은 Ubuntu의 경우 ufw, Debian의 경우 iptables, CentOS의 경우 firewalld입니다. 그러나 iptables는 플랫폼 간에 가장 일관성이 있으며 여기에 연결되는 많은 도구가 있습니다.

SSH

기본 SSH 포트를 표준으로 유지합니다. 포트 변경은 주요 관심사인 특정 상황에서만 수행해야 합니다.

암호 인증을 비활성화하고 루트에 대한 키 전용 인증을 사용하거나 루트 로그인을 완전히 비활성화합니다. 강력한 SSH 키 사용: 최소 2048비트 RSA(4096 권장) 기술적인 이유로 ECDSA는 더 이상 권장되지 않습니다. Ed25519 및 타원 곡선 알고리즘은 충분히 광범위하게 지원되지 않습니다.

모든 대화형 키에는 암호를 사용하되 비대화형 프로세스에는 사용하지 마십시오. 루트 계정에서 사용자 홈 디렉터리로 SSH 키에 대한 소유권을 설정하거나 복사 및 변경합니다. 실용적인 곳에 fail2ban을 설치하십시오.

SSH 에이전트 포워딩은 CoreOS와 같은 플랫폼의 일반 워크플로에 필요하지만 몇 가지 보안 문제가 있습니다. 기본적으로 호스트에 대한 권한이 있는 사람은 누구나 포워딩 소켓을 사용하여 로컬 ssh-agent에 연결할 수 있습니다.

SSL/TLS

사용 편의성을 위해 Let’s Encrypt 사용을 강력히 권장하며 TLS를 권장합니다. 강력한 SSL 보안을 사용하십시오. https://cipherli.st/(최신 및 레거시 권장 사항 모두)를 확인하십시오.

도메인 이름이 없는 호스트의 경우 적절한 강도의 자체 서명된 인증서를 제안합니다. 다시 Nginx를 살펴보십시오.

VPN

서버 간의 일반적인 암호화 통신을 위한 솔루션으로 VPN을 권장합니다. VPN은 서버 간에 여러 서비스를 보호해야 할 때 점점 더 가치가 높아집니다. 각 서비스를 개별적으로 암호화하는 대신 모든 내부 통신을 VPN으로 파이프할 수 있습니다. 이 접근 방식은 해당 서비스가 기본 암호화를 지원하지 않는 경우에 특히 유용합니다.

일반적으로 서버 간 통신을 위해 OpenVPN을 통한 Tinc를 권장합니다. 자세한 내용과 구현에 대해서는 Ansible 및 Tinc에 대한 이 기사를 읽을 수 있습니다.

결론

이것은 본질적으로 독단적이고 생생한 문서이며 자주 업데이트됩니다. 기술은 빠르게 변화하고 DigitalOcean은 따라잡기 위해 최선을 다하지만 오류를 발견하거나 피드백이 있는 경우 아래 의견을 모니터링할 것입니다.