재부팅을 우회하려면 Packer가 HVM에서 resize2fs도 할 수 있게 합니다

안녕하세요. 코미야입니다. 패커의 hvm에서 resize2fs를 허용해서 재부팅을 피하려고 했습니다.

저도 cloud-init을 사용해서 같은 작업을 할 수 있을 것 같아요. CentOS 6(HVM)에서 cloud-init을 설정하고 Amazon Linux | Developers.IO 를 사용 하세요. 하지만 저는 패커를 사용하기 때문에 거기서 하는 게 더 쉽습니다. 아무것도 설정하지 않고 cloud-init만 넣는 AMI를 만들면 로그인할 수 없었습니다. 설정 파일에 쓴 내용과 그 뒤에서 하는 일을 이해하지 못하면 하고 싶지 않은데, 찾아보는 게 번거로웠습니다. 약점이 부족해서 죄송합니다.

·문제의 시작: CentOS6.5에서 AMI를 기반으로 hvm 인스턴스를 만들 때, chef 레시피로 실행해야 했고 resize2fs가 자동으로 루트 볼륨에 구현되었지만 크기는 변하지 않았습니다. 원래는 10GB에서 50GB여야 했지만, 10GB로 유지되었습니다.

‧당분간, 구구루 아래 URL에서 유사한 현상과 대응책에 대해 알아보세요. EC2의 CentOS-HVM으로 디스크 크기 변경 | 핵 fdisk로 확장하는 다른 방법들도 있었다. 하지만 재부팅이 필요하다는 걸 막혔다! 나는 그렇게 생각했다. 구체적으로 resize2fs는 셰프 레시피를 스트리밍하는 방식이라 로그인이 두 번 번거롭다.

·제가 문제를 제기하거나 민감한 분과 상담했는데, 그 분은 파티션 테이블에 문제가 있다면 패커에 다음과 같은 URL을 넣는 게 어떻겠냐고 제안했습니다. CentOS에서 Amazon EC2 | Developers.IO 에서 디스크 크기가 변하지 않을 때 어떻게 해야 하는가

‧사실 시도해봤는데 성공했어.

패커에서 쉘 스크립트에 다음 내용을 추가하세요

+# EPEL에서 growroot 등을 설치하세요
+yum -y --enablerepo=epel install dracut-modules-growroot cloud-utils
+
+# 루트 파티션 테이블 크기 변경
+dracut --force --add growroot /boot/initramfs-$(uName -r).img

그래서 패커로 AMI를 만들고 그 AMI에서 만든 인스턴스에 셰프 레시피를 실행했는데, 디피드를 하자 디스크가 확장되었습니다. 재부팅할 필요가 없었어요! ! 와! 축하합니다.

・packer로 AMI를 빌드하는 방법 설치 과정을 HashiCorp의 Install Packer - Packer에서 확인할 수 있습니다. 템플릿은 다음과 같습니다(vpc를 사용한다면 vpc_id와 subnet_id도 필요합니다). 요즘은 vpc를 사용할 수 없을 수도 있습니다. ）

{ 
  "변수": { 
    "aws_access_key": "AKB**********", 
    "aws_secret_key": "Pga4**********", 
    "aws_source_ami": "ami-53**********", 
    "aws_region_name": "앱-소**********", 
    "aws_instance_type": "t2.small", 
    "aws_vpc_id": "VPC-0z**********", 
    "aws_subnet_id": "서브넷-0**********", 
    "aws_create_date": "" 
  }, 
  "빌더스": [{ 
    "Type": "amazon-ebs", 
    "access_key": "{{user 'aws_access_key'}}", 
    "secret_key": "{{user 'aws_secret_key'}}", 
    "region": "{{user 'aws_region_name'}}", 
    "source_ami": "{{user 'aws_source_ami'}}", 
    "instance_type": "{{user 'aws_instance_type'}}", 
    "ssh_username": "뿌리", 
    "ssh_timeout": "10m", 
    "subnet_id": "{{user 'aws_subnet_id'}}", 
    "vpc_id": "{{user 'aws_vpc_id'}}", 
    "associate_public_ip_address": 맞아, 
    "ami_name": "AMI_standard_{{user 'aws_create_date'}}", 
    "태그": { 
      "이름": "AMI_standard_{{사용자 'aws_create_date'}}" 
    }
  }], 
  "보급자들": [{ 
    "type": "shell", 
    "execute_command": "sh {{ . 경로 }} {{user 'aws_region_name'}}", 
    "스크립트": "ami-deploy.sh" 
  }]
}

*프로비저너에서 실행할 스크립트를 지정하세요 이 페이지 [게시판]Packer | Ryuzee.com로 다양한 가상 머신용 템플릿 생성하기. 설명도 있습니다. 스크립트를 위해 직접 AMI를 만들 때 기본 기본 설정을 준비하는 것이 좋습니다. 내용은 cloud-init에서 준비하는 것과 같거나, 셰프 이전 설정이 장난스럽습니다. 예를 들어, 일반 저장소와 ssh, 최소 사용자, 자동 시작 설정 등 모든 것에 절대적으로 포함된 저장소 등이 있습니다. *우선, 템플릿에 지정된 AMI는 hvm이 필요합니다. 작성 방법에 관한 Inada 씨의 기사를 참고하세요. ⇒ PV 인스턴스에서 HVM 인스턴스로 변환하기 (CentOS6)

빌드 명령은 다음과 같이 실행됩니다: (표준 출력에 다양한 실행 상태가 있으므로 백그라운드로 전달하지 않는 것이 좋습니다)

CREATE_DATE='date +'%Y%m%d''
Packer build -var aws_create_date=${CREATE_DATE} templatefile.json

*약 20~30분 정도 걸렸습니다. 윈도우에서 실행할 수 있는 것 같은데, 리눅스로 할 수 있는 리눅스가 처리 성능이 더 좋아서 윈도우에서 하면 막히는 것 같습니다. 심리적인 장벽이 높아서 동기부여가 안 됩니다.

당분간은 개인적으로 쉽게 목표를 달성할 수 있었기에 여기 있습니다. 곧 cloud-init을 알아보고 싶습니다. 뇌에서 우선순위가 낮은 작업 (강제로 기회가 없으면 혼란스러울 것 같아요).

시청해 주셔서 감사합니다.