1. Зачем такой бАаальшой docker run для gitlab мы же решили использовать docker-compose )
2. Образ gitlab/gitlab-ce:latest конечно официальный, но по мне удобнее sameersbn/docker-gitlab.
Вообще у товарища sameersbn на github много интересных образов.
3.
Важный момент: удаление контейнера не означает удаление данных, которые были созданы в процесе использования системы. Поэтому вы можете выполнять эту команду без каких-либо опасений.
Это не совсем правда!
Лучше это объяснить так:
опция docker run --volume «связывает» (линкует) папку хоста и образа. При использовании этой опции можно хранить данные контейнера хранятся на хосте и поэтому не исчезнут при удалении обновлении и вообще смене образ
4 Опять про volume:
во всех настройках данные расшарины абы как. Где-то пути относительные "./api:/src/app", где-то относительные. Когда контейнеров много можно и заплутать, если надо что-то исправить.
Предлагаю небольшой хак чтобы не все было прозрачно.
хранить все данные в одном формате:
/srv/docker/someImage/…
А еще лучше в домашней папке пользователя
~/docker/someImage/…
5. Все docker-compose в git
6. Все установки на сервере загонять в ansible (или любой другой инструмент для оркестрации) и тоже все в гит
7. Как решен вопрос с запуском всего этого после перезагрузки сервера?
8. На самом деле не понятно какая цель работы? gitlab + LAMP (MEAN)? приватные репозитории + хостинг проекта?
Тогда бы надо осветить wworkflow код -> gitlab -> ci -> LAMP
После одного недавнего проекта осталось несколько мыслей по поводу перевода.
1 Тексты это косвенные данные проекта. Не следует их засовывать в код через require. Это приведет к тому, что из-за изменения текстов придется пересобирать проект.
Гораздо проще засунуть их в Глобал.
2. Не надо привязывать Тексты жёстко к компонентам.
Например, з я сделал так, добавил в компонент свойство text. Компонент знает только об схеме этого свойства, т.е о доступных ключах.
Так же сделал простой декоратор @ text который из Глобал объекта тянет нужный ключ в компонент.
2. Образ gitlab/gitlab-ce:latest конечно официальный, но по мне удобнее sameersbn/docker-gitlab.
Вообще у товарища sameersbn на github много интересных образов.
3.
Это не совсем правда!
Лучше это объяснить так:
опция docker run --volume «связывает» (линкует) папку хоста и образа. При использовании этой опции можно хранить данные контейнера хранятся на хосте и поэтому не исчезнут при удалении обновлении и вообще смене образ
4 Опять про volume:
во всех настройках данные расшарины абы как. Где-то пути относительные "./api:/src/app", где-то относительные. Когда контейнеров много можно и заплутать, если надо что-то исправить.
Предлагаю небольшой хак чтобы не все было прозрачно.
хранить все данные в одном формате:
/srv/docker/someImage/…
А еще лучше в домашней папке пользователя
~/docker/someImage/…
5. Все docker-compose в git
6. Все установки на сервере загонять в ansible (или любой другой инструмент для оркестрации) и тоже все в гит
7. Как решен вопрос с запуском всего этого после перезагрузки сервера?
8. На самом деле не понятно какая цель работы? gitlab + LAMP (MEAN)? приватные репозитории + хостинг проекта?
Тогда бы надо осветить wworkflow код -> gitlab -> ci -> LAMP
1 Тексты это косвенные данные проекта. Не следует их засовывать в код через require. Это приведет к тому, что из-за изменения текстов придется пересобирать проект.
Гораздо проще засунуть их в Глобал.
2. Не надо привязывать Тексты жёстко к компонентам.
Например, з я сделал так, добавил в компонент свойство text. Компонент знает только об схеме этого свойства, т.е о доступных ключах.
Так же сделал простой декоратор @ text который из Глобал объекта тянет нужный ключ в компонент.