Archive for 4월, 2018

netflix ioensrc titus

2018/04/30
YdXRwSEn_normal.png InfoQ (@InfoQ)
2018. 4. 29. 오전 12:03
Netflix Open Sources Its Container Management Platform Titus bit.ly/2r5x4uG by @talonx

트위터 앱 다운로드

나의 iPhone에서 보냄

Advertisements

jenkins-script-console-scripts/README.md at master · samrocketman/jenkins-script-console-scripts · GitHub

2018/04/29

jenkins-script-console-scripts/README.md at master · samrocketman/jenkins-script-console-scripts · GitHub

https://github.com/samrocketman/jenkins-script-console-scripts/blob/master/README.md

Presentation: Incident Management at Netflix Velocity

2018/04/26

—-
Presentation: Incident Management at Netflix Velocity
// InfoQ

Davbig-1524703607712.JPG

Dave Hahn talks about how Netflix engineering teams think about failure, the tools, techniques, and training they use to shorten the inevitable failures of their systems and impacts to their customers. He explains why they believe chaos is their friend, failure is guaranteed, and why Netflix is better off having both.

By Dave Hahn
—-

Read in my feedly

나의 iPhone에서 보냄

Configuring a Jenkins Pipeline using a YAML file

2018/04/25

—-
Configuring a Jenkins Pipeline using a YAML file
// Jenkins Blog

This guest post was originally published on Wolox’s Medium account here.

A few years ago our CTO wrote about building a Continuous Integration server for Ruby On Rails using Jenkins and docker. The solution has been our CI pipeline for the past years until we recently decided to make an upgrade. Why?

  • Jenkins version was way out of date and it was getting difficult to upgrade
  • Wolox has grown significantly over the past years and we’ve been experiencing scaling issues
  • Very few people knew how to fix any issues with the server
  • Configuring jobs was not an easy task and that made our project kickoff process slower
  • Making changes to the commands that each job runs was not easy and not many people had permissions to do so. Wolox has a wide range of projects, with a wide variety of languages which made this problem even bigger.

Taking into account these problems, we started digging into the newest version of Jenkins to see how we could improve our CI. We needed to build a new CI that could, at least, address the following:

  • Projects must be built using Docker. Our projects depend on one or multiple docker images to run (app, database, redis, etc)
  • Easy to configure and replicate if necessary
  • Easy to add a new project
  • Easy to change the building steps. Everyone working on the project should be able to change if they want to run npm install or yarn install.

Installing Jenkins and Docker

Installing Jenkins is straightforward. You can visit Jenkins Installation page and choose the option that best suits your needs.

Here are the steps we followed to install Jenkins in AWS:

sudo rpm — import https://pkg.jenkins.io/debian/jenkins.io.key sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins.io/redhat/jenkins.repo sudo yum install java-1.8.0 -y sudo yum remove java-1.7.0-openjdk -y sudo yum install jenkins -y sudo yum update -y sudo yum install -y docker

Automatically adding projects from Github

Adding projects automatically from Github can be achieved using the GitHub Branch Source Plugin. It allows Jenkins to scan a GitHub organization for projects that match certain rules and add them to Jenkins automatically. The only constraint that all branches must meet in order to be added is that they contain a Jenkinsfile that explains how to build the project.

Easy to change configuration

Not so easy to change configuration

One of the biggest pains we had with our previous Jenkins was the difficulty of changing the steps necessary to build the project. If you looked at a project’s build steps, you would find something like this:

#!/bin/bash +x set -e # Remove unnecessary files echo -e "\033[34mRemoving unnecessary files...\033[0m"
rm -f log/*.log &> /dev/null || true &> /dev/null
rm -rf public/uploads/* &> /dev/null || true &> /dev/null

# Build Project
echo -e "\033[34mBuilding Project...\033[0m"
docker-compose --project-name=${JOB_NAME} build

# Prepare test database
COMMAND="bundle exec rake db:drop db:create db:migrate"
echo -e "\033[34mRunning: $COMMAND\033[0m"
docker-compose --project-name=${JOB_NAME} run  \
-e RAILS_ENV=test web $COMMAND

# Run tests
COMMAND="bundle exec rspec spec"
echo -e "\033[34mRunning: $COMMAND\033[0m"
unbuffer docker-compose --project-name=${JOB_NAME} run web $COMMAND

# Run rubocop lint
COMMAND="bundle exec rubocop app spec -R --format simple"
echo -e "\033[34mRunning: $COMMAND\033[0m"
unbuffer docker-compose --project-name=${JOB_NAME} run -e RUBYOPT="-Ku" web $COMMAND
And some post build steps that cleaned up the docker:

#!/bin/bash +x
docker-compose --project-name=${JOB_NAME} stop &> /dev/null || true &> /dev/null
docker-compose --project-name=${JOB_NAME} rm --force &> /dev/null || true &> /dev/null
docker stop `docker ps -a -q -f status=exited` &> /dev/null || true &> /dev/null
docker rm -v `docker ps -a -q -f status=exited` &> /dev/null || true &> /dev/null
docker rmi `docker images --filter 'dangling=true' -q --no-trunc` &> /dev/null || true &> /dev/null
Although these commands are not complex, changing any of them required
someone with permissions to modify the job and an understanding ofwhat
needed to be done.

Jenkinsfile to the rescue…​ or not

With the current Jenkins version, we can take advantage of
Jenkins Pipeline and model our build
flow in a file. This file is checked into the repository and, therefore,
anyone with access to it can change the build steps. Yay!

Jenkins Pipeline even has support for:

  • Docker and
    multiple
    images
    can be used for a build!
  • Setting environment variables with withEnv and many other built -in
    functions that can be found
    here.
This makes a perfect case for Wolox. We can have
our build configuration in a file that’s checked into the repository and
can be changed by anyone with write access to it. However, a Jenkinsfile
for a simple rails project would look something like this:

# sample Jenkinsfile. Might not compile
node {
checkout scm
withEnv(['MYTOOL_HOME=/usr/local/mytool']) { docker.image("postgres:9.2").withRun() { db -> withEnv(['DB_USERNAME=postgres', 'DB_PASSWORD=', "DB_HOST=db", "DB_PORT=5432"]) { docker.image("redis:X").withRun() { redis -> withEnv(["REDIS_URL=redis://redis"]) { docker.build(imageName, "--file .woloxci/Dockerfile .").inside("--link ${db.id}:postgres --link ${redis.id}:redis") { sh "rake db:create" sh "rake db:migrate" sh "bundle exec rspec spec" } } } } } } }

This file is not only difficult to read, but also difficult to change. It’s quite easy to break things if you’re not familiar with Groovy and even easier if you know nothing about how Jenkins’ pipeline works. Changing or adding a new Docker image isn’t straightforward and might lead to confusion.

Configuring Jenkins Pipeline via YAML

Personally, I’ve always envied simple configuration files for CIs and this time it was our chance to build CI that could be configured using a YAML file. After some analysis we concluded that a YAML like this one would suffice:

config: dockerfile: .woloxci/Dockerfile project_name: some-project-name services: - postgresql - redis steps: analysis: - bundle exec rubocop -R app spec --format simple - bundle exec rubycritic --path ./analysis --minimum-score 80 --no-browser setup_db: - bundle exec rails db:create - bundle exec rails db:schema:load test: - bundle exec rspec security: - bundle exec brakeman --exit-on-error audit: - bundle audit check --update environment: RAILS_ENV: test GIT_COMMITTER_NAME: a GIT_COMMITTER_EMAIL: b LANG: C.UTF-8

It outlines some basic configuration for the project, environment variables that need to be present during the run, dependentservices, and our build steps.

Jenkinsfile + Shared Libraries = WoloxCI

After investigating for a while about Jenkins and the pipeline, we found that we could extend it with shared libraries. Shared libraries are written in groovy and can be imported into the pipeline and executed when necessary.

If you look carefully at this Jenkinsfile, we see that the code is a chain of methods calls that receive a closure, where we execute another method passing a new closure to it.

# sample Jenkinsfile. Might not compile node { checkout scm withEnv(['MYTOOL_HOME=/usr/local/mytool']) { docker.image("postgres:9.2").withRun() { db -> withEnv(['DB_USERNAME=postgres', 'DB_PASSWORD=', "DB_HOST=db", "DB_PORT=5432"]) { docker.image("redis:X").withRun() { redis -> withEnv(["REDIS_URL=redis://redis"]) { docker.build(imageName, "--file .woloxci/Dockerfile .").inside("--link ${db.id}:postgres --link ${redis.id}:redis") { sh "rake db:create" sh "rake db:migrate" sh "bundle exec rspec spec" } } } } } } }

Groovy is flexible enough to allow this same declarative code to be created at runtime, making our dream of using a YAML to configure our job come true!

Introducing Wolox-CI

That’s how wolox-ci was born- our shared library for Jenkins!

With wolox-ci, our Jenkinsfile is now reduced to:

@Library('wolox-ci') _ node { checkout scm woloxCi('.woloxci/config.yml'); }

Now it simply checks out the code and then calls wolox-ci. The library reads yaml file like this one

config: dockerfile: .woloxci/Dockerfile project_name: some-project-name services: - postgresql - redis steps: analysis: - bundle exec rubocop -R app spec --format simple - bundle exec rubycritic --path ./analysis --minimum-score 80 --no-browser setup_db: - bundle exec rails db:create - bundle exec rails db:schema:load test: - bundle exec rspec security: - bundle exec brakeman --exit-on-error audit: - bundle audit check --update environment: RAILS_ENV: test GIT_COMMITTER_NAME: a GIT_COMMITTER_EMAIL: b LANG: C.UTF-8

and builds the Jenkinsfile to get your job running on the fly.

The nice part about having a shared library is that we can extend and fix our library in a centralized way. Once we add new code, the library is automatically updated in Jenkins which will notify all of our jobs with the update.

Since we have projects in different languages we use Docker to build the testing environment. WoloxCI assumes there is a Dockerfile to build and will run all the specified commands inside the container.

Woloxci config.yml

Config

The first part of the config.yml file specifies some basic configuration: project’s name and Dockerfile location. The Dockerfile is used to build the image where the commands will be run.

Services

This section describes which services will be exposed to the container. Out of the box, WoloxCI has support for postgresql, mssql and redis. You can also specify the docker image version you want! It is not hard to add a new service. You just need to add the corresponding file at

https://github.com/Wolox/wolox-ci/tree/development/vars

and modify how the services are parsed

https://github.com/Wolox/wolox-ci/blob/development/src/com/wolox/parser/ConfigParser.groovy#L76

Steps

The listed commands in this section will run inside the Docker container. As a result, you’ll see each of the steps on the Jenkins UI.

image

Environment

If you need some environment variables during your build, you can specify them here. Whatever variable you set will be available inside the Docker container when your commands listed in the steps section described above.

Wrapping up

WoloxCI is still being tested with a not-so-small sample of our projects. The possibility of changing the build steps through a YAML file makes it accessible for everyone and that is a great improvement in our CI workflow.

Docker gives us the possibility of easily changing the programming language without making any changes to our Jenkins installation and Jenkins’ Github Organization feature automatically adds new projects when a new repository with a Jenkinsfile is detected.

All of these improvements have reduced the time we spend maintaining Jenkins significantly and give us the possibility of easily scaling without any extra configuration.

This library is working in our CI but it still can be improved. If you would like to add features, feel free to contribute!

—-

Read in my feedly

나의 iPhone에서 보냄

Ndc18 “게임에서 즐겁게 반복플레이 할 수 있는 방법은? ”

2018/04/25

—-
[Ndc18] “게임에서 즐겁게 반복플레이 할 수 있는 방법은?”
// 지디넷코리아 – 전체기사

[지디넷코리아]

넥슨의 김창섭 메이플스토리팀 기획자는 넥슨 개발자 컨퍼런스2018(NDC2018)에서 ‘오래해도 재미있는 게임을 만들기 위한 메이플스토리의 시도들’이라는 주제로 발표했다.

이번 발표는 메이플스토리를 사례로 온라인게임에서 반복플레이를 이용자가 부담 없이 즐겁게 즐길 수 있는 방안에 대해 소개됐다.

김창섭 기획자는 온라인게임에서 반복 플래이가 필요한 이유는 양질의 콘텐츠를 제공하기 위한 플레이타임을 마련하기 위해서라고 설명했다. 결말 없이 지속되는 게임인 만큼 다양한 이용자의 취항과 플레이방식에 맞춘 콘텐츠를 제공해야 하기 때문이다.

넥슨코리아 김창섭 기획자.

그는 이용자가 오래해도 재미있는 반복플레이를 위해 필요한 요소로 오래할 거리 만들기, 지루함 줄이기, 다른 할 거리 제안하기 등 세가지를 소개했다.

먼저 김창섭 기획자는 오래할 거리 만들기가 포함된 시스템으로 유니온시스템을 예로 들었다.

그동안 온라인게임은 플레이타임을 늘리기 위해 캐릭터를 성장시킬수록 다음 레벨업에 도달하기 위한 레벨업 목표치가 기하급수적으로 늘어다. 이로 인해 요구되는 플레이시간이 늘어나고 성취감을 얻은 빈도가 낮아져 반복플레이의 재미가 떨어진다.

메이플스토리팀은 계정 내 모든 캐릭터 레벨의 총합이 높아지면 혜택을 제공하는 유니온시스템을 통해 빠른 성장 구간을 반복해서 즐길 수 있도록 방향을 바꿨다.

이용자가 부담없이 반복 플레이를 할 수 있도록 기획된 유니온 시스템.

하나의 캐릭터를 만렙인 250까지 한번에 키우는 것이 아니라 40종의 캐릭터를 돌려가며 성장속도가 빠른 140레벨까지만 키우도록 반복플레이의 방향을 수정한 것이다.

더불어 메이플스토리팀은 성장시킨 캐릭터가 늘어날수록 추가 능력치를 주거나 성장시킨 모든 캐릭터가 한 곳에서 몬스터를 사냥하는 유니온 레이드를 통해 성장의 재미를 더했다.

김창섭 기획자는 이 업데이트를 통해 140레벨 이상 캐릭터 비율이 증가했고 낮은 구간 레벨 캐릭터는 감소하는 등 캐릭터 성장을 유도했을 뿐 아니라 캐릭터 누적레벨이 4천 레벨 이상을 넘어서는 하드코어 이용자가 3배 이상 증가했다고 성과를 밝혔다.

온라인게임에서 지루함은 주로 의사결정이나 강한 몬스터 등으로 이용자에게 스트레스를 주지 않으려는 과정에서 오히려 큰 위험 없이 같은 작업을 반복할 때 발생한다.

메이플스토리팀은 일반적인 반복사냥에 작은 도전과 성공 등을 경험할 수 있는 콘텐츠를 추가해 지루함을 해결했다.

다양한 콘텐츠를 통해 이용자가 성장할 수 있는 선택지를 제공했다.

예를 들어 다수의 몬스터를 연달아 잡으면 멀티킬 보너스를 제공하고 맵에 무작위로 등장하는 룬을 발동 시키면 추가 혜택이 일정시간 주어지는 식이다.

이 밖에도 엘리트몬스터 처치 등 미션을 해결하면 잡으면 다양한 보상이 주어지는 돌발미션과 공간을 변화시쳐 시청각적인 경험을 환기시키는 폴로&프리토 미션 등이 있다.

김 기획자는 이러한 콘텐츠 추가를 통해 월 평균 이용자 플레이 타임이 10~15% 이상 증가했다고 설명했다.

세 번째인 다른 할 거리 제안하기는 기존 사냥과 다른 게임플레이를 통해 비슷한 수준의 성취를 제공함으로써 반복플레이라는 느낌을 줄이는 방식이다.

주요 콘텐츠로는 설귀도탐험열차, 니할사막의 무역왕, 몬스터 택시 운전사 등으로 제한 시간 동안 같은 목표를 다른 방법으로 달성할 수 있는 선택지를 제공해 이용자가 원하는 콘텐츠를 플레이할 수 있는 자유와 새로운 룰을 학습하는 재미를 제공하는 것이다.

김창섭 기획자는 월간 유니트이용자 중 약 23% 가 해당 콘텐츠를 즐겼으며 서로 신규 콘텐츠에 대한 공략을 공유하는 등 바이럴 마케팅 효과도 얻을 수 있었다고 소개했다.

끝으로 그는 “오래해도 재미있는 게임을 만드는다는 것은 이용자가 빠져나가지 못하게 막는 것이 아니라 언제든 켜서 논 후 빠져 나올 수 있는 인생을 함께하는 게임이라고 생각한다”며 발표를 마쳤다.

▶ IT 세상을 바꾸는 힘 <지디넷코리아>,
▶ IT뉴스는 <지디넷코리아>, 게임트렌드는 <뉴스앤게임>
▶ 스마트폰으로 읽는 실시간 IT뉴스 <모바일지디넷>
[저작권자ⓒ메가뉴스 & ZDNet & CNET. 무단전재 및 재배포 금지]
—-

Read in my feedly

나의 iPhone에서 보냄

스타일쉐어는 어떻게 ‘무통장 입금’ 오류 줄였을까?

2018/04/25

—-
스타일쉐어는 어떻게 ‘무통장 입금’ 오류 줄였을까?
// 지디넷코리아 – 전체기사

[지디넷코리아]

스타일쉐어가 무통장 입금의 한계로 초래되는 이른바 ‘미확인 입금자를 찾습니다’ 문제를 해결하는 결제 시스템을 소개해 업계 관계자들의 이목이 집중됐다.

이 회사가 공개한 솔루션은 카드, 간편결제를 이용하기 어려운 10대 이용자들을 위해 고안된 진보된 결제 시스템이다.

스타일쉐어의 박성환 프로덕트매니저는 앱 조사기관 앱애니가 24일 노보텔 엠배서더 강남에서 개최한 ‘2018 앱애니 세미나’에서 ‘밀레니얼 세대의 커머스’란 주제로 발표했다.

2011년 설립된 스타일쉐어는 의류 리뷰를 중심의 SNS로 시작했으나, 2년 전 쇼핑 기능을 추가해 통합 의류 리뷰 플랫폼으로 성장했다.

스타일쉐어 박성환 프로덕트매니저

박 매니저에 따르면 스타일쉐어는 동종업체 대비 1.7배 높은 방문회수를 기록할 정도로 인기가 있다. 특히 10대 이용자들이 등하교 시간에, 20~30대 이용자들이 출퇴근 시간에 간편하게 스타일쉐어에 접속하는 것으로 나타났다.

박 매니저는 “스타일쉐어가 쇼핑 기능을 추가하면서 10대 이용자들의 구매 패턴에 대한 데이터를 확보할 수 있었다”며 “이들은 공통적으로 상품 결제 시 ‘무통장 입금’을 선택하고 있는 것으로 집계됐다”고 밝혔다. 전체 이용자들 중 무통장 입금을 선택하는 비율은 10%밖에 되지 않지만 유독 10대 이용자들은 무통장 입금을 이용했다는 설명이다.

이어 “카드, 간편결제 및 휴대폰 결제, 무통장 입금, 가상계좌, 계좌이체 등 5가지 기본적인 결제 방법이 있는데 10대 이용자들은 특히 무통장 입금 방법을 많이 선택했다”며 “10대들은 신용카드를 갖기 어렵고, 부모가 휴대폰 요금을 충당해 허락을 받아야 하며 현금으로 용돈으로 받아 계좌이체를 이용하기 어렵다”고 말했다.

하지만 무통장 입금으로 결제 시 구매자와 판매자의 매칭 확률도 떨어져, 입금을 했음에도 상품을 받지 못하는 이용자가 발생했다. 또 100원 단위로 입금하지 못해 입금 정보와 일치하지 않는 경우가 빈번했다.

이에 박 매니저는 이같은 무통장 입금의 한계를 극복하기 위해 ‘자동매칭’ 시스템과 ‘ATM’ 기능을 도입했다고 설명했다.

자동매칭 시스템은 입금확인 불가 케이스를 결제 데이터에서 모두 추출해 대표적인 케이스로 로직화 한 것이다. 입금자명에 은행명이 자동으로 붙는 경우나, 여러 주문건에 대해 한번에 입금을 하더라도 자동매칭 시스템을 거치면 구매자와 판매자의 매칭 확률은 높아진다.

ATM은 결제 금액을 100원, 1천원 단위를 올림해 무통장 입금하면 이후 포인트로 즉시 환급해해주는 기능이다.

박 매니저는 “전체 주문 건의 25%가 ATM 기능을 이용해 결제됐으며 이로 인해 ‘미확인 입금자를 찾습니다’와 같은 CS 문의도 30% 넘게 감소했다”며 “자동매칭 로직 추가와 ATM 기능으로 매칭 확률을 현재 98%까지 끌어올렸다”고 밝혔다.

▶ IT 세상을 바꾸는 힘 <지디넷코리아>,
▶ IT뉴스는 <지디넷코리아>, 게임트렌드는 <뉴스앤게임>
▶ 스마트폰으로 읽는 실시간 IT뉴스 <모바일지디넷>
[저작권자ⓒ메가뉴스 & ZDNet & CNET. 무단전재 및 재배포 금지]
—-

Read in my feedly

나의 iPhone에서 보냄

문자메시지를 컴퓨터로 보내는 방법

2018/04/23

—-
문자메시지를 컴퓨터로 보내는 방법
// ITWorld Korea

문자 메시지는 보통 휴대전화에서 휴대전화로 전송되지만, 배터리가 다 되었거나 스마트폰이 손에 닿지 않는 경우 노트북이나 PC를 사용하지 않을 이유가 없다. PC에서 문자 메시지를 보내는 방법은 다음과 같다. 컴퓨터에서 문자 메시지를 보낼 수 있는 기능은 당장 필요해지기 전까지는 생각하지 못할 수 있다. 하지만 설치하기 쉽고 일단 한번 사용하면 …
—-

Read in my feedly

나의 iPhone에서 보냄

5~10초 안에 정답… :: 네이버 뉴스

2018/04/23

5~10초 안에 정답… :: 네이버 뉴스

http://m.news.naver.com/read.nhn?oid=032&aid=0002865397&sid1=105&mode=LSD

View & Outlook 간식냉장고는 직원들 배만 채울뿐 사업하는 이유 가르쳐야 `헌신` 나온 다 :: 매일경제 뉴스

2018/04/22

[View & Outlook] 간식냉장고는 직원들 배만 채울뿐 사업하는 이유 가르쳐야 `헌신` 나온다 :: 매일경제 뉴스

http://news.mk.co.kr/newsRead.php?year=2018&no=251992

DevOps and Cloud InfoQ Trends Report – January 2018

2018/04/20

DevOps and Cloud InfoQ Trends Report – January 2018

https://www.infoq.com/articles/devops-cloud-trends