{
    "version": "https:\/\/jsonfeed.org\/version\/1.1",
    "title": "Discover Docker, K8s and Hashicorp Nomad with Maksym Prokopov: posts tagged gitlab",
    "_rss_description": "The blog about containerisation, virtual machines and useful shell snippets and findings",
    "_rss_language": "en",
    "_itunes_email": "",
    "_itunes_categories_xml": "",
    "_itunes_image": "",
    "_itunes_explicit": "",
    "home_page_url": "https:\/\/blog.it-premium.com.ua\/tags\/gitlab\/",
    "feed_url": "https:\/\/blog.it-premium.com.ua\/tags\/gitlab\/json\/",
    "icon": false,
    "authors": [
        {
            "name": "Maksym Prokopov",
            "url": "https:\/\/blog.it-premium.com.ua\/",
            "avatar": false
        }
    ],
    "items": [
        {
            "id": "217",
            "url": "https:\/\/blog.it-premium.com.ua\/all\/the-gitlab-pecularities\/",
            "title": "The Gitlab pecularities",
            "content_html": "<p>For a very long time, I used to work with Jenkins most of my work time, but since my new job, I have to spend more time with Gitlab and started having a bunch of  WTFs. So here is my list:<\/p>\n<ol start=\"1\">\n<li>Caching. Distributed cache requires S3 implementation. Here is free one: <a href=\"https:\/\/min.io\/\">https:\/\/min.io\/<\/a><\/li>\n<li>Stages. Stages are not the same stages as Jenkins has, these are naturally separate jobs with the separate BUILD_IDs, so you’d better use CI_PIPELINE_ID.<\/li>\n<li>Declarative pipeline. The only YAML can be used with its pros and cons, but having Gitlab Actions is mainstream nowadays.<\/li>\n<li>Files. You can’t store ssh key as a file in GitLab, only like a variable. That means you need to create one using echo $variable in your script. With proper permissions.<\/li>\n<\/ol>\n",
            "date_published": "2020-03-25T08:51:08+01:00",
            "date_modified": "2020-03-25T08:51:05+01:00",
            "tags": [
                "gitlab"
            ],
            "_date_published_rfc2822": "Wed, 25 Mar 2020 08:51:08 +0100",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "217",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "216",
            "url": "https:\/\/blog.it-premium.com.ua\/all\/what-to-do-if-gitlab-cache-doesnt-work\/",
            "title": "What to do if Gitlab cache doesn’t work?",
            "content_html": "<p>That seems to be a peculiarity of the Gitlab because of its nature.<\/p>\n<p>The thing is that local cache is really local to the particular runner, so if you use shared runners each next task will be assigned most probably to the different runner(node). In this way you will not have the same cache unless you’re using distributed cache stored on S3.<\/p>\n<p>The easiest way to tackle this is to use a tag for each of your stage. Thus it’s going to stick to particular runner.<\/p>\n",
            "date_published": "2020-03-24T10:42:00+01:00",
            "date_modified": "2020-03-24T10:41:58+01:00",
            "tags": [
                "gitlab"
            ],
            "_date_published_rfc2822": "Tue, 24 Mar 2020 10:42:00 +0100",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "216",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "165",
            "url": "https:\/\/blog.it-premium.com.ua\/all\/dockerized-gitlab-registry-nginx-proxy-container-with-ssl\/",
            "title": "Dockerized Gitlab + Registry + nginx-proxy container with SSL",
            "content_html": "<p>For me worked following configuration for jwilder\/nginx-proxy container.<\/p>\n<pre class=\"e2-text-code\"><code class=\"\">web:\n  image: &#039;gitlab\/gitlab-ce:latest&#039;\n  hostname: &#039;gitlab.it-expert.com.ua&#039;\n  environment:\n    GITLAB_OMNIBUS_CONFIG: |\n      external_url &#039;https:\/\/gitlab.it-expert.com.ua&#039;\n      registry_external_url &#039;https:\/\/registry.it-expert.com.ua&#039;\n    VIRTUAL_HOST: gitlab.it-expert.com.ua,registry.it-expert.com.ua\n    VIRTUAL_PORT: 443\n    VIRTUAL_PROTO: https\n  volumes:\n    - &#039;.\/data\/config:\/etc\/gitlab&#039;\n    - &#039;.\/data\/logs:\/var\/log\/gitlab&#039;\n    - &#039;.\/data\/data:\/var\/opt\/gitlab&#039;<\/code><\/pre><p>Tricky part was to figure out how containers is connected and which and who should process SSL.<\/p>\n<p>For this configuration you should supply SSL certificates both for nginx-proxy and gitlab-ce containers, because communications between them is also using SSL. For gitlab-ce use .\/data\/config\/ssl folder.<\/p>\n",
            "date_published": "2016-11-08T13:27:38+01:00",
            "date_modified": "2016-11-08T13:27:35+01:00",
            "tags": [
                "docker",
                "gitlab",
                "nginx"
            ],
            "_date_published_rfc2822": "Tue, 08 Nov 2016 13:27:38 +0100",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "165",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "highlight\/highlight.js",
                    "highlight\/highlight.css"
                ],
                "og_images": []
            }
        },
        {
            "id": "112",
            "url": "https:\/\/blog.it-premium.com.ua\/all\/gitlab-timezone-dlya-kieva\/",
            "title": "GITLAB_TIMEZONE для Киева",
            "content_html": "<p>Правильно указывать в docker-compose.yml так<\/p>\n<p>GITLAB_TIMEZONE=Kyiv<\/p>\n",
            "date_published": "2016-05-05T16:18:01+01:00",
            "date_modified": "2016-05-05T16:17:59+01:00",
            "tags": [
                "docker",
                "gitlab"
            ],
            "_date_published_rfc2822": "Thu, 05 May 2016 16:18:01 +0100",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "112",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "55",
            "url": "https:\/\/blog.it-premium.com.ua\/all\/kak-prosche-vsego-podnyat-docker\/",
            "title": "Как проще всего поднять docker",
            "content_html": "<p>Моя инструкция для Ubuntu:<\/p>\n<ol start=\"1\">\n<li>Добавляем репозиторий для свежего docker.<\/li>\n<li>Ставим через apt-get docker-engine<\/li>\n<li>Ставим docker-compose.  <br \/>\ncurl -L <a href=\"https:\/\/github.com\/docker\/compose\/releases\/download\/1.5.0rc1\/docker-compose-\">https:\/\/github.com\/docker\/compose\/releases\/download\/1.5.0rc1\/docker-compose-<\/a>`uname -s`-`uname -m` > \/usr\/local\/bin\/docker-compose<br \/>\nи делаем его исполняемым<\/li>\n<\/ol>\n<p>chmod +x \/usr\/local\/bin\/docker-compose<\/p>\n<ol start=\"4\">\n<li>Забираем через git docker-compose.yml и стартуем как docker-compose up.<br \/>\nПосле этого этапа все должно завестись.<\/li>\n<li>Настраиваем автозапуск через систему upstart<\/li>\n<\/ol>\n<p>\/etc\/init\/gitlab.conf<br \/>\ndescription “Gitlab docker containers”<br \/>\nauthor “Me”<br \/>\nstart on filesystem and started docker<br \/>\nstop on runlevel [!2345]<br \/>\nrespawn<br \/>\nchdir \/home\/nexus\/docker.src\/docker-gitlab\/<\/p>\n<p>script<br \/>\n\/usr\/local\/bin\/docker-compose start -d<br \/>\nend script<\/p>\n",
            "date_published": "2015-10-28T10:24:08+01:00",
            "date_modified": "2015-10-23T13:54:23+01:00",
            "tags": [
                "gitlab",
                "ubuntu"
            ],
            "_date_published_rfc2822": "Wed, 28 Oct 2015 10:24:08 +0100",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "55",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        }
    ],
    "_e2_version": 4134,
    "_e2_ua_string": "Aegea 11.3 (v4134)"
}