사용자 정의 FreeBSD AMI에서 사용자 데이터 스크립트를 실행하는 방법은 무엇입니까?

사용자 정의 FreeBSD AMI에서 사용자 데이터 스크립트를 실행하는 방법은 무엇입니까?

EC2 AMI에서는 사용자 데이터를 한 번만 실행할 수 있다는 것을 읽었습니다. EC2 인스턴스에서 사용자 지정 AMI를 생성하는 경우 사용자 지정 AMI에서 사용자 데이터 스크립트를 실행할 수 없습니다. Ubuntu 인스턴스에서는 /var/lib/cloud/*를 삭제하고, 사용자 지정 AMI를 생성하고, 사용자 지정 AMI에서 사용자 데이터를 실행할 수 있습니다. FreeBSD에서 /var/lib/cloud/*에 해당하는 항목을 찾을 수 없습니다.

사용자 정의 FreeBSD AMI에서 userdata를 실행하는 방법이나 userdata 스크립트를 다시 실행할 수 있도록 AMI를 생성하는 대안이 있습니까?

Linux에는 #cloud-boothook이 있지만 FreeBSD에서는 내 필요에 맞지 않는 configinit만 찾았습니다. 인스턴스를 시작할 때 명령줄에서 사용자 데이터 스크립트로 매개변수를 전달합니다.

답변1

AWS의 FreeBSD AMI는 다른 AMI와 동일한 수준의 user_data 스크립트 지원을 제공하지 않습니다. 지적했듯이 #cloud-boothookuser_data를 지원하지 않으며 시작 후 전달된 user_data를 무시합니다.

간단한 해결책은 다음과 같습니다.

sed -i '' '/KEYWORD: *firstboot$/d' /usr/local/etc/rc.d/ec2_configinit

이것은 해킹입니다. 이제 인스턴스는 태그가 없는 스크립트도 포함하여 모든 user_data 스크립트를 실행 #cloud-boothook하지만 제 생각에는 스크립트의 기본 동작보다 훨씬 낫습니다. 사람들은 항상 ec2_configinit에 액세스 할 수 있습니다 /etc/rc.conf.

답변2

허용되는 답변이 매우 거칠기 때문에 나만의 답변을 제공하고 있습니다.

업데이트: 허용된 답변이 꽤 거칠다고 생각했지만 결국 사용하게 되었습니다.왜냐하면 그것이 나에게 가장 잘 어울리기 때문이다. 나머지 부분은 일부 사람들에게 유용할 수 있는 추가 배경 정보를 제공하기 위한 것입니다. (1) 항상 쉘 스크립트를 실행할 수 있고, (2) 아래 설명하는 것처럼 사용자 데이터 파일을 처리하는 것 외에는 아무 것도 수행하지 않으며, (3) 다음과 같은 이유로 허용된 대답이 나에게 가장 적합했습니다. 원한다면 rc.conf에서 이를 비활성화할 수 있습니다.

문제는 Amazon Linux에서도 MIME 멀티파트/믹싱 트릭을 사용하지 않는 한 사용자 데이터 스크립트가 첫 번째 부팅 시에만 실행된다는 것입니다. 당신은 확인할 수 있습니다https://cloudinit.readthedocs.io/en/latest/topics/format.html하지만 저는 한계를 뛰어넘는 예를 들었습니다.

Content-Type: multipart/mixed; boundary="schnipp-schnapp"
MIME-Version: 1.0

--schnipp-schnapp
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"

#cloud-config
cloud_final_modules:
- [scripts-user, always]

--schnipp-schnapp
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="user-data.sh"

#!/bin/bash
echo "Hello World." >> /etc/motd

--schnipp-schnapp
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="another.sh"

#!/bin/bash
echo "Kilroy was here." >> /etc/motd

--schnipp-schnapp
Content-Type: image/jpeg
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="imput64-8503-small.jpg"

/9j/4AAQSkZJRgABAQEAlgCWAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcU
FhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgo
...
JFSUkfQjjHr9yT2T9SSSdLS15R/qM64pbLRUcsExOk6axzpxhiQATFSDIB6E68K/c6WlrzEoTypl
JoceL9zq7NbXis8oopa6RRNUQovmNlCM5IIzxQLkgkD0wQCAFLYaXzKkSSVEkzOZXqJJOUjsfXkf
cknJOMk++lpa9u+AGkJwsuJACiqCeJGm5pJiZJXBr4Sx04IfzZiS3I9r3/TQakADkD260tLWjxQk
hE9/tVFgPm8K/9k=

--schnipp-schnapp--

두 스크립트가 모두 알파벳순으로 실행되고 이미지 부분이 무시되는 것을 발견했습니다.

FreeBSD AMI 관리자가 이 멀티파트 콘텐츠와 그에 관련된 모든 것을 구현하지 않는 한

  • 텍스트/클라우드 안내
  • 텍스트/클라우드 구성
  • 텍스트/클라우드 구성 아카이브
  • 텍스트/jinja2
  • 텍스트/섹션 핸들러
  • 텍스트/뉴 리치 워크
  • 텍스트/x-include-once-url
  • 텍스트/x-include-url
  • 텍스트/x-쉘 스크립트

ec2-cloudinit가 수행하는 다른 모든 작업이 항상 이와 같이 수행될 것으로 기대하는 이유는 무엇입니까? 결국 당신은 혼자입니다.

사용자 데이터를 얻고 이를 어떻게 처리할지 직접 결정하는 데는 아무런 해가 없습니다. 얻는 방법은 다음과 같습니다.

fetch -q -o - http://169.254.169.254/latest/user-data

따라서 실행하고 싶다면 rc.local에 넣으면 됩니다:

fetch -q -o - http://169.254.169.254/latest/user-data |sh 

또는

fetch -q -o /tmp/user-data.sh http://169.254.169.254/latest/user-data
mkdir 700 /tmp/user-data.sh
/tmp/user-data.sh

정말 별거 아닙니다. 복잡한 다중 부분 구조를 지원하는 것이 가치가 있는지 확실하지 않습니다. FreeBSD AMI는 이를 매우 다르게 수행하고 더 간단하며 틀림없이 나쁘지 않습니다.

  • hash-bang #!으로 시작하면 저장되고 실행됩니다.
  • "">/var/tmp/here"로 시작하면 지정된 대상에 기록됩니다.
  • ">>/var/tmp/here"로 시작하면 지정된 대상에 추가됩니다.
  • 그렇지 않으면 쉘 스크립트의 압축되지 않은 tar 아카이브로 처리되어 확장된 다음 위의 규칙을 사용하여 각 파일이 실행됩니다.

AWS 표준이 아니므로 그대로 두겠습니다. 스크립트를 갖고 rc.local에서 강제로 실행하거나 실행하지 않고 어떤 방식으로든 동작을 제어하는 ​​매개변수를 찾으면 됩니다.

관련 정보