ВС
в разных, предыдущий раз загрузился
а на самом сервере есть таймаут?
Size: a a a
2020 October 13
EK
нет, пока я разберусь как это делать, рабочий день закончится. Проблема в заголовке каком-нибудь. Не думаю, это облако
AS
на каком балансировщике? мне надо только что сформированный отчет загрузить
а куда ты грузишь, кстати, сформированный отчёт? )
EK
у меня скрипт состоит из двух частей, запись в csvб потом чтение. Вот второй раз запустил скрипт с уже сформированный отчетом, все загрузилось ок
ВС
нет, пока я разберусь как это делать, рабочий день закончится. Проблема в заголовке каком-нибудь. Не думаю, это облако
ну go вот при таком способе отдает запрос с Transfer-Encoding: chunked, хотя вот кстати именно для файла может быть исключение (по крайней мере в http.FileServer такое есть)
AS
нет, пока я разберусь как это делать, рабочий день закончится. Проблема в заголовке каком-нибудь. Не думаю, это облако
curl-ом туда же, на тот же сервер, с того же сервера, где приложение, отправлял этот же файл?
EK
ну зависить одно от другого же не может, я файл закрываю после записи и заново открываю
EK
curl-ом туда же, на тот же сервер, с того же сервера, где приложение, отправлял этот же файл?
отправлял с php
AS
у меня скрипт состоит из двух частей, запись в csvб потом чтение. Вот второй раз запустил скрипт с уже сформированный отчетом, все загрузилось ок
CSV-то сжатый хоть? ))
А
Александр
Всех приветствую!
Интересует мнение общества по поводу сборки проекта через docker где поставлять надо конкретно исполняемый "файл", а не в виде пуша образа в докер репозиторий.
Возник рабочий момент с двумя мнениями.
Описано немного утрировано, что-то опущено.
1 вариант. Собирать проект внутри контейнера, предварительно скопировав исходники в образ. Примерно так:
Собирать
Плюсы: так "принято", везде подобные примеры.
Минусы: думаю что надо регулярно чистить ненужные множащиеся образы, тк зависимости иногда меняются, а исходники всегда. В других Го проектах образы будут расти начиная с зависимостей.
2 вариант. Собирать проект снаружи, но конейнером - сборщиком. Примерно так
Собирать
Минусы: в этом варианте возникла проблема что gitlab не может удалить созданные каталоги/файлы тк владелец их root. Победить через USER или --user и их сочетания пока не привели к успеху.
Плюсы: исходники не копируются, образ будет один и не будет меняться от сборки к сборке. В других проектах будет использоваться этот же образ.
Я склоняюсь ко второму варианту, но меня склоняют к первому :)
Поделитесь опытом. Может я что-то упустил или еще не узнал?
Интересует мнение общества по поводу сборки проекта через docker где поставлять надо конкретно исполняемый "файл", а не в виде пуша образа в докер репозиторий.
Возник рабочий момент с двумя мнениями.
Описано немного утрировано, что-то опущено.
1 вариант. Собирать проект внутри контейнера, предварительно скопировав исходники в образ. Примерно так:
FROM golang...
...установка mingw-w64, сертификатов и тд...
COPY go.mod go.sum ./
RUN go mod download
COPY . .
VOLUME ["/builded"]
RUN go build -o /builded/... cmd/*.go
Собирать
docker run --rm ..skip.. -v "....:/builded" myimageПлюсы: так "принято", везде подобные примеры.
Минусы: думаю что надо регулярно чистить ненужные множащиеся образы, тк зависимости иногда меняются, а исходники всегда. В других Го проектах образы будут расти начиная с зависимостей.
2 вариант. Собирать проект снаружи, но конейнером - сборщиком. Примерно так
FROM golang...
...установка mingw-w64, сертификатов и тд...
VOLUME [ "/project" ]
VOLUME [ "/go/pkg" ]
WORKDIR /project
Собирать
docker run --rm ..skip.. -v "$(CURDIR):/project" -v "$(GOPATH)/pkg:/go/pkg" myimage go mod download && go build -o builded/... cmd/*.goМинусы: в этом варианте возникла проблема что gitlab не может удалить созданные каталоги/файлы тк владелец их root. Победить через USER или --user и их сочетания пока не привели к успеху.
Плюсы: исходники не копируются, образ будет один и не будет меняться от сборки к сборке. В других проектах будет использоваться этот же образ.
Я склоняюсь ко второму варианту, но меня склоняют к первому :)
Поделитесь опытом. Может я что-то упустил или еще не узнал?
Прошу прощения, вчера поздно написал и похоже затерялось.
EK
CSV-то сжатый хоть? ))
нет
EK
в облаке его потом расжать нельзя
EK
или вы про заголовки?
АП
а что решаете то?
АП
пересылка сверхбольшого csv по сети без загрузки памяти?
ВС
отправлял с php
а в php у вас есть http2? а то с ним иногда приколы бывают
AS
большой файл таким образом не загружается, получаю ошибку Put url/test2.csv: unexpected EOF
сними дамп трафика tcpdump-ом )) да покажь его
AS
в облаке его потом расжать нельзя
а зачем тебе он в облаке в таком размере? )
AS
Александр
Прошу прощения, вчера поздно написал и похоже затерялось.
1. чем не устраивает вариант 1? ))
2. как именно задавали USER?
2. как именно задавали USER?
S
Александр
Всех приветствую!
Интересует мнение общества по поводу сборки проекта через docker где поставлять надо конкретно исполняемый "файл", а не в виде пуша образа в докер репозиторий.
Возник рабочий момент с двумя мнениями.
Описано немного утрировано, что-то опущено.
1 вариант. Собирать проект внутри контейнера, предварительно скопировав исходники в образ. Примерно так:
Собирать
Плюсы: так "принято", везде подобные примеры.
Минусы: думаю что надо регулярно чистить ненужные множащиеся образы, тк зависимости иногда меняются, а исходники всегда. В других Го проектах образы будут расти начиная с зависимостей.
2 вариант. Собирать проект снаружи, но конейнером - сборщиком. Примерно так
Собирать
Минусы: в этом варианте возникла проблема что gitlab не может удалить созданные каталоги/файлы тк владелец их root. Победить через USER или --user и их сочетания пока не привели к успеху.
Плюсы: исходники не копируются, образ будет один и не будет меняться от сборки к сборке. В других проектах будет использоваться этот же образ.
Я склоняюсь ко второму варианту, но меня склоняют к первому :)
Поделитесь опытом. Может я что-то упустил или еще не узнал?
Интересует мнение общества по поводу сборки проекта через docker где поставлять надо конкретно исполняемый "файл", а не в виде пуша образа в докер репозиторий.
Возник рабочий момент с двумя мнениями.
Описано немного утрировано, что-то опущено.
1 вариант. Собирать проект внутри контейнера, предварительно скопировав исходники в образ. Примерно так:
FROM golang...
...установка mingw-w64, сертификатов и тд...
COPY go.mod go.sum ./
RUN go mod download
COPY . .
VOLUME ["/builded"]
RUN go build -o /builded/... cmd/*.go
Собирать
docker run --rm ..skip.. -v "....:/builded" myimageПлюсы: так "принято", везде подобные примеры.
Минусы: думаю что надо регулярно чистить ненужные множащиеся образы, тк зависимости иногда меняются, а исходники всегда. В других Го проектах образы будут расти начиная с зависимостей.
2 вариант. Собирать проект снаружи, но конейнером - сборщиком. Примерно так
FROM golang...
...установка mingw-w64, сертификатов и тд...
VOLUME [ "/project" ]
VOLUME [ "/go/pkg" ]
WORKDIR /project
Собирать
docker run --rm ..skip.. -v "$(CURDIR):/project" -v "$(GOPATH)/pkg:/go/pkg" myimage go mod download && go build -o builded/... cmd/*.goМинусы: в этом варианте возникла проблема что gitlab не может удалить созданные каталоги/файлы тк владелец их root. Победить через USER или --user и их сочетания пока не привели к успеху.
Плюсы: исходники не копируются, образ будет один и не будет меняться от сборки к сборке. В других проектах будет использоваться этот же образ.
Я склоняюсь ко второму варианту, но меня склоняют к первому :)
Поделитесь опытом. Может я что-то упустил или еще не узнал?
что то непонятно где во втором варианте поставка артефакта в builded если он незамаплен как VOLUME?
и go mod download в обоих случаях будет скачивать модули, разве нет?
и go mod download в обоих случаях будет скачивать модули, разве нет?