Re: Github Proje Yükleme
Latia Shiels
8. Şimdi artık proje dosyalarımızı ykleme zamanı. Tek yapmamız gereken C:\Belgeler\GitHub dizinine gittiğimizde ilk-proje adında bir klasrmzn oluştuğunu greceksiniz. Buraya yklemek istediğiniz projenin kodlarını veya herhangi bir şeyi ykleye bilirsiniz. rnek olarak logo.png adında bir grsel ykledim. Sizde projelerinizi buraya srekle bırak yaparak ekleyebilirsiniz.
İyi gnler ok gzel anlatmışsınız proje ykleme olayını ellerinize sağlık. Bir sorum olacak benim ben projeyi private olarak ykleyip birisine yetki vermem gerekiyor. Bu işlemi nasıl yapabilirim? hızlı dnş sağlarsanız ok mutlu olurum
On balenaCloud, when we deploy code to devices grouped in a fleet, they all run what we refer to as a "release". A release consists of a Docker image or set of images on our registry. These images are built from a source code repository, either locally or remotely on the balenaCloud build server. When a successful release is created, all devices in the fleet are instructed to download and run the new release (according to the chosen update strategy).
There are 3 ways to create and deploy a release, namely balena push, balena deploy and git push. Each method has slightly different use cases and differ on how and where the container images are built. We'll explain each of the options in more detail below. If you are just starting out with balenaCloud, we recommend using balena push.
balena push is the recommended method for deployment and development on the balenaCloud platform. To use balena push you need to first install the balena CLI and ensure you are logged in to your account with balena login.
When you run the balena push command from your laptop it will essentially take your project (or repository) folder, compress it and send it to the balenaCloud build server or local balenaOS device in localMode where it will be built.
Once the cloud builder has successfully completed building all the images in the deployment, it will upload these images to the balenaCloud registry and create a release entry in the balena API database. It will then notify all the devices in the fleet that a new release is available. If you need to pull in proprietary code or use a private base image during your builds, you can do so using the build time secrets or private base images feature of balena push.
It should be noted that balena push is independent of git, so you are free to use any version control system you wish. This also means that it is possible to use git submodules in your project when deploying with balena push.
The balena deploy is functionally very similar to balena push but avoids pushing any source code to the balenaCloud build server. It gives more control over how and where your container images are built, allowing for balena deploy to be integrated into your own CI/CD build system.
With balena build container images are built on your development machine or on a remote machine, by specifying a docker daemon's IP address and port number with the relevant command-line options (for example a device running a balenaOS development image). Depending on your fleet's targeted CPU architecture builds will be run emulated via qemu.
If you are building your own container images, balena deploy will upload the images to the balenaCloud image registry and then create a release entry in the balena API database. The devices in the fleet will then be notified of a new release and download it. Should balena deploy not find the required images on the specified docker daemon, it will automatically trigger a build.
The git push balena master method of deployment is the original deployment mechanism for balenaCloud. While we continue to support git push, it is considered a legacy method for pushing code to a fleet, and if possible you should use balena push as it makes for a consistent workflow and methodology.
Then, simply add your balenaCloud app's git endpoint to your local git repository via git remote add balena . You can find the fleet git remote endpoint by clicking the 'Add release' button in the releases tab of the dashboard.
Warning: The balenaCloud git repository is not intended as a code hosting solution, and we cannot guarantee the persistence of data in balenaCloud git remotes. We recommend you use a service like GitHub to manage and share your code.
To completely change the code you have pushed to a fleet with git you will need to force a rewrite of the git remote endpoint's history. To do this, you just need to run the same command with the -f flag from the new project you wish to deploy. For example:
The git push workflow is a great way to deploy code, but it has a number of limitations when compared to balena push and balena deploy. One is mentioned above, where it is necessary to rewrite the history and force push to completely change the source code and build a new release from scratch.
In order to allow options like emulation and nocache, the git push workflow uses specifically named remote branches (see next section) however, this has the limitation that it is not possible to invalidate the cache of an emulated build pushed with git push.
Like balena push the git push workflow also allows triggering a build that invalidates the Docker layer cache and builds from scratch. This can be achieved by pushing to a special branch called balena-nocache as shown in the example below:
When deploying a balena project, the build system will try to build the most appropriate release for a specific set of devices. The following section will discuss some of the mechanisms you can use to control the type of builds that are produced.
This resolution mechanism looks at the files in the root of the directory you are deploying. If it finds a docker-compose.yml file, it will ignore all the other types and build a multicontainer release based on the service specification in the docker-compose.yml file.
If docker-compose.yml is not specified, the resolution system will assume a single container deployment and will build based on a Dockerfile.* file. These Dockerfiles can have extensions of ., . or .template, and the build system will use the most appropriate file based on the targeted device or fleet. This is best described with an example:
When we push this project to a fleet that has its default device type set to Raspberry Pi 3, the build system will use the device type specific Dockerfile.raspberrypi3 file to build from. If we instead pushed this to an Intel NUC fleet, the build would use the Dockerfile.amd64 file. When pushing to any other device type, the regular Dockerfile would be used to perform the build. This type of project selection will also work in service folders of multicontainer deployments; you can see an example of that in our Getting started with multicontainer project.
The file extensions are equivalent to BALENA_MACHINE_NAME for . and BALENA_ARCH for . from the template files discussed in the next section. To find the correct name have a look at our machine names and architectures list.
Often it's desirable to create a single Dockerfile that can be used and built for multiple different device types and CPU architectures. In this case, a Dockerfile.template file can be used. This dockerfile template will replace the template variables before the build is started. Currently the builder supports the following build variables:
In many cases, you will want to deploy container images from a private Docker Hub account or a personally hosted registry. In order to do this, you need to enable balena to authenticate with the private registry during the build, which is done by passing the --registry-secrets option with a path to the authentication secrets. An example is shown below:
It should be noted that in this case, the devices will still pull the container images from the balenaCloud registry. The authentication just allows the build step access to pull your private image at build time.
Often it is necessary to use passwords or secrets during your build to fetch proprietary files or code but not have these sensitive files be downloaded to all the devices. For this reason balena push and balena deploy allow defining a .balena folder to hold secret files and variables that will get exposed to the image build but not propagate down to devices.
To use build secrets, make a subdirectory .balena in the root of your repository. Inside that directory, make anotherdirectory named secrets and a file named balena.yml. Without any secrets, your tree should look like:
This will mount the super-secret-recipe file into /run/secrets/my-recipe file in every build container. However, the /run/secrets folder will not be added to the build context that is sent to the Docker daemon (or balenaEngine),and therefore:
This will mount the super-secret-recipe file as /run/secrets/my-recipe for all services, and super-secret-recipe-2 as /run/secrets/my-recipe2 for service1 only. Again, note that the /run/secrets folder is only available during the image build, and not present in the image that is deployed to the devices.
Note: Currently balena build and balena deploy do not support build time secret files out of the box and need to be pointed to a balenaEngine instance. Refer to the balena build and balena deploy command references for additional documentation.
Build variables should NOT be used to hold secrets like access tokens or passwords if the Docker image is accessible to untrusted parties, because the Dockerfile ARG instruction may be stored in the image as the Docker documentation advises:
Warning: It is not recommended to use build-time variables for passing secrets like github keys, user credentials etc. Build-time variable values are visible to any user of the image with the docker history command.
If you are interested in seeing an example of build time secrets and variables see this project. Note this is just a toy project and in a real world setting it is not advisable to commit your.balena secrets folder into the git repository. You should always add it to your .gitignore file.
d3342ee215