I build a lot of different projects on my little Macbook Air.
Instead of installing things directly on my machine, I create Docker containers for each project. I’d love to use Fly within Docker to deploy my code.
I can get Flyctl installed / running on my Docker container, but every time I try to fly auth login, it says it logs me in, and then it kills my container.
In fact, it looks like if I start back up, I am still logged in because I can type fly auth whoami or fly auth token and it spits out my email address / token. However, simply running those commands also kills my container because the container receives a SIGTERM.
Any idea why flyctl is killing my containers and how to stop it?
I’d really love to give it a try, but I don’t want to have to build my entire Rails development environment (and install all the gems and stuff) directly on my machine just to test it out.
You don’t need to install your dev environment locally, that’s the beauty of it. By default your app is built with the specified Dockefile remotely in Fly’s cloud (or optionally locally, using Docker).
So, perhaps I’m not understanding the errors I’m facing correctly. When I run fly launch, I get the following error:
To update to the latest version installed on your system, run `bundle update --bundler`.
To install the missing version, run `gem install bundler:2.5.4`
from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems.rb:302:in `activate_bin_path'
from /usr/bin/bundle:23:in `<main>'
Error: Failed to install bundle, exiting: exit status 1
It looks like it’s trying to do this because of my Gemfile.lock.
When I say I don’t want to have to install my dev environment, this is what I mean. I don’t want to have to install RubyGems or run Bundler on my local machine, I’d like to do all of that inside of my Docker container where all of those gems are already installed.
@rubys Here are the relevant portions of my docker-compose.yml and Dockerfile.
Happy to answer any questions you have about these, but I basically just run docker compose up app to start things and then docker compose exec -it app /bin/bash to open a shell and run the fly auth login or fly auth whoami commands. They succeed with output and then immediately send a SIGTERM to the container (totally not sure why).
FROM timbru31/ruby-node:3.3-slim-18
RUN apt-get update -qq && apt-get install -y build-essential postgresql-client
RUN curl -L https://fly.io/install.sh | sh
ENV FLYCTL_INSTALL="/root/.fly"
ENV PATH="$FLYCTL_INSTALL/bin:$PATH"
ENV APP_HOME /home/app
ENV BUNDLER_VERSION='2.5.4'
WORKDIR $APP_HOME
COPY Gemfile Gemfile.* $APP_HOME
RUN gem install bundler --no-document -v ${BUNDLER_VERSION}
RUN bundle install
# Add a script to be executed every time the container starts.
COPY entrypoint.sh /usr/bin/
RUN chmod +x /usr/bin/entrypoint.sh
ENTRYPOINT ["entrypoint.sh"]
EXPOSE 3000
# Configure the main process to run when running the image
CMD ["./bin/dev"]
Thanks! I have an appointment I need to go to so I’ll look at this either tonight or early tomorrow (US EST). In addition to the two problems you noted (flyctl exiting the container and bundler version), I’ll note that that Dockerfile isn’t set up to be run in production. You are going to need a separate Dockerfile and to do one or both of the following:
@rubys Thanks for the reply and offering to look into it / help! I’m in no rush, so please take your time
I was hoping to not even use my Dockerfile. I read somewhere that if you don’t provide one, Fly will generate one with sane defaults for the deploy.
But I was curious what would happen if it found my development one. Should I just rename that one to Dockerfile.dev or something so that Fly doesn’t try to use it?
If you have a file named Dockerfile, it won’t overwrite it, and it will attempt to use it. So, yes, renaming the current Dockerfile to Dockerfile.dev would be a good idea. I was also pointing out that you can do it the other way, but I prefer your suggestion.
Interestingly, if I run docker compose run --rm --service-ports app bash all the commands seem to work fine. It’s only when I run docker compose up and then docker compose exec -it app /bin/bash that it fails, so it must have something to do with either the way I’m launching a shell, or the fact that the Rails app isn’t actually running in the first command.
So, solution right now is use docker compose run app bash instead of docker compose up and things seem to be fine. Although, it did make me login again which was weird.