https://aws.amazon.com/ko/blogs/developer/aws-cdk-developer-preview/ 기계번역문

우리는 TypeScript, JavaScript 및 Java 용 AWS 클라우드 개발 키트 (CDK) 개발자 미리보기 릴리스 를 발표하게 된 것을 기쁘게 생각합니다 .NET 및 Python이 곧 출시 될 예정입니다. AWS CDK는 클라우드 인프라를 코드로 정의하고 CloudFormation을 통해 프로비저닝하는 소프트웨어 개발 프레임 워크입니다. CDK는 AWS 서비스와 완벽하게 통합되며 AWS 리소스를 필수적으로 정의하기 위해 더 높은 수준의 객체 지향 추상화를 제공합니다. CDK는 현대 프로그래밍 언어의 힘을 사용하여 예측 가능하고 효율적인 방식으로 AWS 인프라를 정의하므로 엔드 투 엔드 개발 경험을 향상시킵니다.

CDK를 클라우드 인프라 스트럭처 "컴파일러"로 생각할 수 있습니다. AWS 클라우드 리소스를 추상화하고 AWS 모범 사례를 캡슐화하는 Constructs 라는 고수준 클래스 라이브러리 세트를 제공합니다 구문은 응용 프로그램 인프라를 정확하게 정의하고 모든 복잡한 상용구 논리를 처리하는 개체 지향 CDK 응용 프로그램 으로 함께 스냅 할 수 있습니다 CDK 응용 프로그램을 실행하면 AWS 클라우드 인프라의 "어셈블리 언어"인 CloudFormation 템플릿 으로 컴파일됩니다 그러면 템플릿이 CloudFormation 프로비저닝 엔진에 의해 처리되어 AWS 계정에 배포 될 준비가됩니다. CDK 도구를 사용하면 쉽게 정의 할 수 있습니다.애플리케이션 인프라 스트럭처 스택, CloudFormation 서비스는 스택의 안전하고 신뢰할 수있는 프로비저닝 을 처리합니다.

익숙한 도구

CDK를 통해 우리는 매일 사용하는 친숙한 환경과 팀 워크 플로에 인프라 정의를 가져 와서 가장 편안하고 생산적인 곳에서 만날 수 있습니다. CDK는 사용자가 선호하는 객체 지향 프로그래밍 언어를 지원하므로 루프 및 조건과 같은 코드 논리를 자연스럽게 표현하여 모든 환경 또는 시나리오에 맞게 인프라를 사용자 지정할 수 있습니다. CDK 코드는 코드 일 뿐이므로 인라인 설명서, 리팩토링 도구, 코드 탐색 및 단위 테스트와 같은 기존 IDE 기능이 모두 예상대로 작동합니다. 다음 코드는 가용성 영역 및 지역별 AMI ID와 같은 인프라 스트럭처 논리 및 환경 컨텍스트를 사용하여 단일 코드 기반에서 다른 지역에 대한 다양한 응용 프로그램 스택을 만드는 방법을 보여줍니다. 인프라 정의 복사 및 붙여 넣기가 필요하지 않습니다.

// 현재 지역 / 계정에 대한 AZ 목록 가져 오기

const azs = new cdk.AvailabilityZoneProvider(this).availabilityZones;

 

//이 영역의 특정 Windows 버전에 대한 AMI ID 가져 오기

const ami = new ec2.WindowsImage(ec2.WindowsVersion.WindowsServer2016EnglishNanoBase).getImage(this);

 

for (const az of azs) {

// 가용성 영역을 기반으로 구조체 이름을 렌더링합니다.

const constructName = `InstanceFor${az.replace(/-/g).toUpperCase()}`;

 

new ec2.cloudformation.InstanceResource(thisconstructName, {

imageId: ami.imageId,

availabilityZone: az,

});

}

세부 사항 요약

CDK는 개발자가 최신 프로그래밍 언어와 객체 지향 기술을 사용하여 CloudFormation 템플릿을 생성 할 수있는 최초의 솔루션이 아닙니다. CDK는 AWS 서비스와 완벽하게 통합되어 IAM 정책, 보안 그룹 및 네트워크 구성과 같은 주요 리소스를 자동으로 종합하는 유용한 API를 제공합니다. 예를 들어 인프라에 Amazon Virtual Private Cloud (VPC)를 추가하려면 다음 코드 줄을 CDK 응용 프로그램에 추가하기 만하면됩니다.

new ec2.VpcNetwork(this‘MyVPC’);

CDK 애플리케이션이 컴파일되면 대상 지역의 각 가용 영역에 대한 서브넷과 경로, 경로 표, 서브넷 경로 표 연결, NAT 게이트웨이, 인터넷 게이트웨이 및 필요한 탄성 IP를 정의하는 긴 CloudFormation 템플릿이 생성됩니다 모든 일을하도록하십시오. 스마트 한 기본값 중 일부가 요구 사항을 충족시키지 못하면 VPC 매개 변수를 자신의 값으로 쉽게 재정의 할 수 있습니다.

확장 가능

AWS에서 작성한 CDK Constructs가 제공하는 유용한 API를 활용하는 것 외에도 예측 가능하고 재사용 가능한 코드로 자신 만의 모범 사례를 정의 할 수 있습니다. 예를 들어, 암호화가 활성화 된 S3 버킷을 항상 만드는 CDK 응용 프로그램을 제작하여 팀이 기본적으로 자연스럽게이 작업을 수행 할 수 있습니다.

new s3.Bucket(this‘EncryptedBucket’, {

encryption: s3.BucketEncryption.KmsManaged

});

독창적 인 클라우드 고유의 디자인 패턴을 인코딩하고 특정 사용 사례에 중점을두고 내부적으로나 전 세계와 공유하는 더 높은 수준의 CDK 응용 프로그램을 정의 할 수 있습니다. 우리는 당신이 만든 멋진 것들을보기 위해 기다릴 수 없습니다.

바자Bazaar 방문

우리는 닫힌 성당이 아닌 열린 시장처럼 CDK를 건설하고 있습니다. 아직 끝나지 않았습니다! 참조, 익숙하지 않은 사람들을 위해 성당과 시장 , 두 가지 기본적인 소프트웨어 개발 스타일을 대조 에릭 S. 레이몬드에 의해 에세이이며, 오픈 소스, "감안할 때 충분히 눈알, 모든 버그 얕은하다"인수한다 . 오픈 소스 개발자 미리보기이므로 AWS에서 클라우드 애플리케이션을 개발할 때 CDK를 최고의 경험으로 활용할 수 있도록 도와주십시오. aws-cdk GitHub README 를 방문하여 CDK를 시작하는 방법을 배우십시오. Gitter 에 게시 하여 대화를 시작하고, 개발자와 의견 을 교환하고, 풀 요청을 제출하십시오.귀하의 상품을 기부하거나, 단지 우리에게 관심을 보이기 위해 프로젝트에 별표 를 붙이십시오. 우리는 당신과의 협력을 기대합니다.

출처 : https://stackoverflow.com/questions/43671482/how-to-run-docker-compose-up-d-at-system-start-up


crontab의 @reboot 또는 (옛날 방식) /etc/rc.local 파일을 사용 해도 되지만, 앞에 10초 이상 sleep 을 주지 않으면 실행이 안됩니다.

@reboot (sleep 15s ; cd /myapps ; /usr/local/bin/docker-compose up -d )& 


아래 처럼 system service로 해당 앱을 등록 시켜두면 다른 서비스처럼 자동시작/시작/종료 를 제어할 수 있습니다.

# /etc/systemd/system/docker-compose-app.service

[Unit]
Description=Docker Compose Application Service
Requires=docker.service
After=docker.service

[Service]
Type=oneshot
RemainAfterExit=yes
WorkingDirectory=/srv/docker
ExecStart=/usr/local/bin/docker-compose up -d
ExecStop=/usr/local/bin/docker-compose down
TimeoutStartSec=0

[Install]
WantedBy=multi-user.target


 WorkingDirectory  변수값은 실제  프로젝트 경로로 변경 해야 합니다. 

부팅시 서비스가 자동 시작하도록 설정 합니다.

systemctl enable docker-compose-app

======

zabbix 예제

# /etc/systemd/system/zbx.service

[Unit]
Description=Docker Compose Zabbix Application Service
Requires=docker.service
After=docker.service

[Service]
Type=oneshot
RemainAfterExit=yes
WorkingDirectory=/root/zabbix-docker
ExecStart=/usr/local/bin/docker-compose -f ./docker-compose_v3_centos_mysql_latest.yaml up -d
ExecStop=/usr/local/bin/docker-compose -f ./docker-compose_v3_centos_mysql_latest.yaml down
TimeoutStartSec=0

[Install]
WantedBy=multi-user.target

서비스가 자동 시작 설정

systemctl enable zbx

서비스 시작 

systemctl start zbx

서비스 종료

systemctl stop zbx


'Docker' 카테고리의 다른 글

docker-compose 부팅시 자동 시작하기 / 서비스로 등록하기  (0) 2018.08.14
consul, nomad, vault  (0) 2018.03.18

출처: http://agilemanifesto.org/iso/ko/manifesto.html  http://agilemanifesto.org/iso/ko/principles.html

Principles behind the Agile Manifesto (애자일 소프트웨어 개발 선언)

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을
도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고
있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
공정과 도구보다 개인과 상호작용
포괄적인 문서보다 작동하는 소프트웨어
계약 협상보다 고객과의 협력
계획을 따르기보다 변화에 대응하기

That is, while there is value in the items on
the right, we value the items on the left more.
가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

12 Principles Behind the Agile Manifesto (애자일 선언 이면의 원칙)

We follow these principles:
우리는 다음 원칙을 따른다:

  1. 고객만족 추구
    • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
    • 우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
  2. 요구변경 적극 수용
    • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
    • 비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
  3. 짧은 배포 간격
    • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
    • 작동하는 소프트웨어를 자주 전달하라. 2주 ~ 2개월 정도의 간격으로 하되 더 짧은 기간을 선호하라.
  4. 현업-개발자간 일일 의사소통
    • Business people and developers must work together daily throughout the project.
    • 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.
  5. 동기부여된 사람들 중용. 지원 및 신뢰
    • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
    • 동기가 부여된 사람들을 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.
  6. 면대면 대화
    • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
    • 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.
  7. 작동하는 소프트웨어를 척도로
    • Working software is the primary measure of progress.
    • 작동하는 소프트웨어가 진척의 주된 척도이다.
  8. 지속가능한 개발 장려
    • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
    • 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.
  9. 좋은 기술, 설계에 관심
    • Continuous attention to technical excellence and good design enhances agility.
    • 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.
  10. 단순성 추구
    • Simplicity–the art of maximizing the amount of work not done–is essential.
    • 단순성이 – 안 하는 일의 양을 최대화하는 기술이 – 필수적이다.
  11. 자기조직적 팀
    • The best architectures, requirements, and designs emerge from self-organizing teams.
    • 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.
  12. 정기적으로 효율성 제고
    • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
    • 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.


+ Recent posts