#release-engineering (2018-07)

jenkins_ci All things CI/CD. Specific emphasis on Codefresh and CodeBuild with CodePipeline.

CI/CD Discussions

Archive: https://archive.sweetops.com/release-engineering/

2018-07-30

michal.matyjek avatar
michal.matyjek

Looked at 4-5 docker linters I could find and ran our one of our Dockerfile through them. The two that I liked the most are https://github.com/RedCoolBeans/dockerlint and https://github.com/hadolint/hadolint - the only 2 that complained about the non-array-style CMD or ENTRYPOINT

https://github.com/hadolint/hadolint seems well maintained (last updated 8 days ago) has most stars and forks

I also like the configuration and per-line excludes.

RedCoolBeans/dockerlint

dockerlint - Linting tool for Dockerfiles

hadolint/hadolint

hadolint - Dockerfile linter, validate inline bash, written in Haskell

2018-07-29

michal.matyjek avatar
michal.matyjek

Anyone using dockerfile linter they can recommend?

Erik Osterman avatar
Erik Osterman

A ways back, I had looked into it and didn’t find one that I liked, but that was partially because they were all in either python or ruby.

Erik Osterman avatar
Erik Osterman

If you find one you like, lmk! Would love to add it to our own build harness. I might concede on the ruby/python now :-)

michal.matyjek avatar
michal.matyjek

I don’t think twistlock can do the level of linting we would prefer, so looking for something. I did not realize there are so many (simple google search shows 4-5 right away)

Erik Osterman avatar
Erik Osterman

Also do a GitHub repo search

Erik Osterman avatar
Erik Osterman

@rohit.verma have any linting suggestions

2018-07-27

Erik Osterman avatar
Erik Osterman

@michal.matyjek not sure if this is too complicated of a PR for you take an interest in

Erik Osterman avatar
Erik Osterman
Promote Helm Charts and Docker Images Across Repositories by goruha · Pull Request #85 · cloudposse/build-harness

What Use helm package to change version and app Version of chart Use convention that default image tag is based on app Version Create promote targets that allow to promote chat to required versio…

Erik Osterman avatar
Erik Osterman

but we are working on the ability to easily/cleanly promote images and charts between repositories

Erik Osterman avatar
Erik Osterman

The goal is to be able to do something like

make release/promote \
    CHART_NAME=api-app \
    SOURCE_VERSION=0.1.0 \
    TARGET_VERSION=0.2.0 \
    SOURCE_IMAGE=api-app:0.1.0-sha.a989ads8 \
    TARGET_IMAGE=api-app:0.2.0
michal.matyjek avatar
michal.matyjek

yeah

Erik Osterman avatar
Erik Osterman

(interface not yet formalized)

michal.matyjek avatar
michal.matyjek

we’re not there yet but the more I think about it - this seems to be the way to go

Erik Osterman avatar
Erik Osterman

are you guys using multiple codefresh accounts?

michal.matyjek avatar
michal.matyjek

we are not

Erik Osterman avatar
Erik Osterman

that also seems like a must have

michal.matyjek avatar
michal.matyjek

elaborate?

Erik Osterman avatar
Erik Osterman

it’s the only way to RBAC production kubernetes integration from staging clusters kubernetes integration

michal.matyjek avatar
michal.matyjek

on what you posted - in our flow we may do this for releases, for “master” CI we would autoversion

michal.matyjek avatar
michal.matyjek

RBAC - waiting for CF to implement, on our “must-have” list, last I heard it is in progress

Erik Osterman avatar
Erik Osterman

multi-account is available now I thought

Erik Osterman avatar
Erik Osterman

so you setup all produciton pipelines in the production account

Erik Osterman avatar
Erik Osterman

all staging pipelines in the other account

Erik Osterman avatar
Erik Osterman

that way staging pipelines can never accidentally modify production

michal.matyjek avatar
michal.matyjek

yeah makes sense

Max Moon avatar
Max Moon
Codefresh adds unified support for multi-git provider accounts - Codefresh

Not so long ago, hosting your code on the cloud almost always meant that you used Github. Teams were fairly standardized in their choice of git provider. This is no longer true. Several other solutions are now challenging Github, including Bitbucket and Gitlab. Moreover, several companies have chosen to actually host their code on-premises creating …

:--1:1

2018-07-26

Erik Osterman avatar
Erik Osterman
Codefresh vs. GitlabCI - Which one should you use

Gitlab is one of the supported GIT providers in Codefresh. In this article, we will look at the advantages of Codefresh compared to the GitlabCI platform.

Yoann avatar
Yoann
07:00:32 PM

@Yoann has joined the channel

Max Moon avatar
Max Moon

just a heads up, if anyone else had the “CodeFresh” status check as a passing requirement for PRs, it is no longer. Now your PR will get a status update that is pipeline specific. If you have repos that require the CodeFresh status, disable it in favor of Pipeline status

Erik Osterman avatar
Erik Osterman

thanks @Max Moon! didn’t know that.

Erik Osterman avatar
Erik Osterman

@dave.yu @jonathan.olson

Max Moon avatar
Max Moon

NP!

michal.matyjek avatar
michal.matyjek
09:06:32 PM

@michal.matyjek has joined the channel

1

2018-07-25

Arkadiy avatar
Arkadiy
02:50:15 PM

@Arkadiy has joined the channel

2018-07-24

Erik Osterman avatar
Erik Osterman
07:15:28 PM

@Erik Osterman has joined the channel

Erik Osterman avatar
Erik Osterman
07:15:28 PM

@Erik Osterman set the channel purpose: CI/CD Discussions

rohit.verma avatar
rohit.verma
07:15:29 PM

@rohit.verma has joined the channel

Igor Rodionov avatar
Igor Rodionov
07:15:29 PM

@Igor Rodionov has joined the channel

Jeremy Grodberg avatar
Jeremy Grodberg
07:15:29 PM

@Jeremy Grodberg has joined the channel

Max Moon avatar
Max Moon
07:15:29 PM

@Max Moon has joined the channel

dave.yu avatar
dave.yu
07:15:29 PM

@dave.yu has joined the channel

jonathan.olson avatar
jonathan.olson
07:15:29 PM

@jonathan.olson has joined the channel

aknysh avatar
aknysh
07:15:29 PM

@aknysh has joined the channel

evan avatar
evan
07:15:29 PM

@evan has joined the channel

Erik Osterman avatar
Erik Osterman

@rohit.verma
how to use semantic versioning, I actually couldn’t figure out how to start from a specific version. We have created charts in a repo under path charts/. I have write a make step to detect the charts which are changed. I want to automatically increment their semantic version. Is this something which can be achieve by this module. What I found is it generates semantic version as 0.0.0-sha(commit-id)

Erik Osterman avatar
Erik Osterman

We follow the convention of tightly coupling charts with the micro service. We stick them in the the charts sub folder. The calculus of knowing which charts work with with docker images is a lost cause. The official chart repo by Kubernetes is optimizing a different use case, which is why they have all charts in one repo. The semantic version of our charts is derived from the nearest git tag in the tree. So if no previous tags, then you get 0.0.0.

Erik Osterman avatar
Erik Osterman
Erik Osterman avatar
Erik Osterman

(with codefresh)

Erik Osterman avatar
Erik Osterman
07:19:08 PM

@Erik Osterman set the channel topic: All things CI/CD. Specific emphasis on Codefresh and CodeBuild with CodePipeline.

Erik Osterman avatar
Erik Osterman

@Igor Rodionov is working on a way to promote charts and images between repos (for @Jeremy Grodberg)

rohit.verma avatar
rohit.verma

the rational of defining charts in a separate repos are

  1. Encapsulate ops from devs (both code and structure wise)
  2. Within dev.niki.ai we have the required service/helmfile with image tags, which makes sense to us to syncup whole infra from one repo
  3. The infra-changes (including services) can be monitored in one Pull request
  4. Even we can move chartmuseum to gitlab pages in future, or if we got a chance to free chart hosting service, it can be synced up using 1 repo only
Erik Osterman avatar
Erik Osterman


Encapsulate ops from devs (both code and structure wise)

rohit.verma avatar
rohit.verma

What I was looking up from SEMVER is a way to incrementally update the semantic version only

Erik Osterman avatar
Erik Osterman

isn’t that antithetical from devops?

rohit.verma avatar
rohit.verma

i think restriction is unethical, encapsulation is not

Erik Osterman avatar
Erik Osterman

i want the developers to write the charts to deploy their apps

Erik Osterman avatar
Erik Osterman

i’ll write one as an example, they write the rest

Erik Osterman avatar
Erik Osterman

when their app architecture changes, I won’t know

Erik Osterman avatar
Erik Osterman

they should update the chart respectively

rohit.verma avatar
rohit.verma

I never mentioned that dev’s shouldn’t commit on other repos, but this won’t be as frequent as the code commits

Erik Osterman avatar
Erik Osterman

i think the semver stuff will work though for your use case anyways

Erik Osterman avatar
Erik Osterman

but versioning your charts will be manual

rohit.verma avatar
rohit.verma

even that is also one point,

  1. Seperate pipelines for charts and code
Erik Osterman avatar
Erik Osterman

the same way they are versioned in kubernetes/charts

Erik Osterman avatar
Erik Osterman

but the pipeline will generate the semvers for the docker containers

Erik Osterman avatar
Erik Osterman

and will pass that to the chart as the image tag to deploy

Erik Osterman avatar
Erik Osterman

our strategy has been to pin charts to containers

Erik Osterman avatar
Erik Osterman

that way for every single version on an app, there’s a chart that will deploy it

Erik Osterman avatar
Erik Osterman

makes it very easy to maintain and understand what’s going on. departing from that will introduces new challenges.

rohit.verma avatar
rohit.verma

in place of pinning to charts, i think this it should be pinned to helmfile

rohit.verma avatar
rohit.verma

version of charts is entirely separate thing than version of code

Erik Osterman avatar
Erik Osterman

but there’s no artifact storage for helmfiles

rohit.verma avatar
rohit.verma

it can still be managed in same way, using yq

Erik Osterman avatar
Erik Osterman
  - name: '{{ env "RELEASE_NAME" }}'
    labels:
      chart: "somechart"
      component: "app"
    version: '{{ env "CHART_VERSION" }}'
    chart: 'chart-repo/{{ env "CHART_NAME" }}'
    namespace: '{{ env "NAMESPACE" }}'
    values:
      - '{{ env "RELEASE_NAME" }}.yaml'
Erik Osterman avatar
Erik Osterman

so that’s the helmfile from a microservice that says how to deploy it

Erik Osterman avatar
Erik Osterman

the envs come from the pipeline

rohit.verma avatar
rohit.verma

you could add image tag also as part of set

Erik Osterman avatar
Erik Osterman

yep

Erik Osterman avatar
Erik Osterman

so that’s the way to do it if you want to decouple the charts from the service repo

rohit.verma avatar
rohit.verma

the point is that, charts represent how a service should run infrastructure wise, but not what a service is running

rohit.verma avatar
rohit.verma

what a service is, its being defined by container

Erik Osterman avatar
Erik Osterman

something similar could be said for the Dockerfile, no?

Erik Osterman avatar
Erik Osterman

OS ~~ Dockerfile ~~service

rohit.verma avatar
rohit.verma

not at all, its all about how we package the service

Erik Osterman avatar
Erik Osterman

cluster ~~ chart ~~docker

rohit.verma avatar
rohit.verma
service ~~ Dockerfile cluster ~~chart release ~ version
rohit.verma avatar
rohit.verma

services are tightly coupled with dockerfile, we can’t use one service’s dockerfile for another

Erik Osterman avatar
Erik Osterman

if using a monochart (declarative helm chart) for multiple services, i think it makes sense to move it out

Erik Osterman avatar
Erik Osterman

but if a chart is 1:1 to a service, there’s no overwhelming reason to separate them

rohit.verma avatar
rohit.verma

to be frank we are not using monochart but the same replica of chart for each service

rohit.verma avatar
rohit.verma

just in case we need to modify something

rohit.verma avatar
rohit.verma

its like we have 3 charts

rohit.verma avatar
rohit.verma

external, internal, job

rohit.verma avatar
rohit.verma

all external services had just required external chart, nothing else

rohit.verma avatar
rohit.verma

all internal services require internal chart

Erik Osterman avatar
Erik Osterman

but our differences aside, I think doing what you said with passing the image tag in the helmfile from an ENV

rohit.verma avatar
rohit.verma

and same for jobs

Erik Osterman avatar
Erik Osterman

will accomplish what you want in the end, no?

rohit.verma avatar
rohit.verma

kind of, its more of doing a git commit on service updates within helmfile

Erik Osterman avatar
Erik Osterman

(i want to move to a monochart for new services so they all follow a similar architecutre)

rohit.verma avatar
rohit.verma

yeah but everything apart => I doubt we have a function which do this, Input => 1.0.0 Output => 1.0.1

Erik Osterman avatar
Erik Osterman

yea, we don’t do that

Erik Osterman avatar
Erik Osterman

knowing when to bump versions I think requires a human

Erik Osterman avatar
Erik Osterman
04:17:19 AM
Erik Osterman avatar
Erik Osterman

our semantic versioning takes the x.y.z from the most recent tag

Erik Osterman avatar
Erik Osterman

and computes metadata based on branch information (for staging environments)

Erik Osterman avatar
Erik Osterman

(so what we’re doing is really not that magical at all)

    keyboard_arrow_up