Rundeck을 사용한 Giithub 연합의 후원이 좌절되면

개시하다
지난번에도 기츠허브를 사용한 런덱의 백업(복구)을 만들려고 하다가 좌절한 그 말을 썼다.
후기만 쓰려고 했는데 하는 일이 많아졌다.
꺾인 말
나는 먼저 멋진 절차를 밟고 싶어서 새로운 Rundeck을 제정하고 Git Import을 할 계획이다.
다음 글을 응용하여 새로운 Rundeck을 만들었습니다.
SCM 구성
마지막으로 설정한 Rundeck에서 프로젝트 기밀 키 객체 항목을 전송하고 Setup SCM에서 Git Import을 설정합니다.
설정해야 하는 항목은 Git Export보다 적고 2곳에 불과합니다.

Giit URL은 작성된 저장소를 지정합니다.

SSH Key Storage Path에서 방금 keystorage에 설정한 내용을 지정합니다.

SCM Plugin Setup Compulete 가 나타나면 설정이 완료됩니다.

예를 들어, Job 화면에 추가된 내용이 있으므로 Import Remote Changes를 선택합니다.

사실 막 시작하려고 할 때 이렇게 됐어요.plugen이 부족합니다.좌절했습니다.

그나저나 여기까지는 다른 곳에서도 여럿 빠져서 실용적이지 못했어요.
그럼 어떡해.
먼저'Git Export''Git Import'에 설정된 Rundeck을 준비해 Job을 모두 삭제하고 깨끗하게 만듭니다.(안 해도 돼)

AWS Constore로 천천히 이동하여 객체 Rundeck의 이미지를 만듭니다.
이미지 명칭이 맞아도 괜찮아요.

이미지가 있으면 해당 AMI에서 새 인스턴스를 시작합니다.

새로 만든 Rundeck을 사용하여 Import Remote Changes를 다시 실행합니다.

Giithub은 마음대로 차분을 흡수하여 Job을 최신 상태로 진입시킬 수 있다.홀가분하다.

만약 이런 형식이라면 비밀 키와 플러그인을 옮기지 않아도 같은 물건을 사용할 수 있기 때문에 최소한의 작업시간으로 Rundeck을 백업할 수 있다.
또 이 경우 AMI에서 시동을 걸어도 그 기간이 비어 있어 지티허브가 차점을 흡수하기 때문에 AMI 측 버전 관리가 필요하지 않다.
이렇게 되면 AMI를 활용하는 것도 힘들지 않겠죠.(플러그인을 추가할 때 버전 차이가 나더라도)
단점은 액티비티를 유지할 수 없다는 것이다.(단, 액티비티를 감사에 사용한다면 외부에 있겠지, 문제없겠지)
후기
나는 원래 지난번 기사를 쓸 때 이 Rundeck이 AMI에서 무한히 증식하면 재미있을 거라고 생각했다.
예컨대 창고는 공통적이며 공식적으로 사용된 런덱에서 유출된 뒤 공식적으로 사용된 잡으로 이동하고, 개발용이라면 개발용 잡으로 이동하는 구조
Job 생성용 Dev-Rundeck에서 Job을 제작하고, Job 실행 권한만 있는ops-Rundeck에서 엔지니어가 아닌 경우 셀프 서비스로 수행합니다.
(ops-rundeck의 ACL은 매우 번거롭다)
꿈이 커졌다.
또 이번에 주목한 것은rundeck이다.org의 규격이 바뀌었습니다. 공식적으로는 최신판만 설치할 수 있습니까?감각이 되다.
과거 버전이 사용된 것 같아서packeagecloud 기사를 먼저 업데이트합니다.